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1 . This Commercial Mobile Alert System First Report and Order (CMAS First Report and 
Order) represents our next step in establishing a Commercial Mobile Alert System (CMAS), under which 
Commercial Mobile Service (CMS) providers 1 may elect to transmit emergency alerts to the public. We 
take this step in compliance with section 602(a) of the WARN Act, 2 which requires the Commission to 
adopt "relevant technical standards, protocols, procedures, and other technical requirements" based on the 
recommendations of the Commercial Mobile Service Alert Advisory Committee (CMSAAC) "necessary 
to enable commercial mobile service alerting capability for commercial mobile service providers that 
voluntarily elect to transmit emergency alerts." 

2. In this CMAS First Report and Order, we adopt rules necessary to enable CMS alerting 
capability for CMS providers who elect to transmit emergency alerts to their subscribers. Specifically, we 
adopt the architecture for the CMAS proposed by the CMSAAC and conclude that a Federal Government 
entity should aggregate, authenticate, and transmit alerts to the CMS providers. In addition, we adopt 
technologically neutral rules governing: 

• CMS provider-controlled elements within the CMAS architecture {e.g., the CMS Provider 
Gateway, CMS Provider infrastructure and mobile devices); 

• Emergency alert formatting, classes, and elements: Participating CMS Providers must transmit 
three classes of alerts - Presidential, Imminent Threat, and AMBER alerts; 

• Geographic targeting (geo-targeting): Participating CMS Providers generally are required to 
target alerts at the county-level as recommended by the CMSAAC; 

• Accessibility for people with disabilities and the elderly: Participating CMS Providers must 
include an audio attention signal and vibration cadence on CMAS-capable handsets; 

• Multi-language Alerting: Participating CMS Providers will not be required at this time to 
transmit alerts in languages other than English; 

• Availability of CMAS alerts while roaming: Subscribers receiving services pursuant to a roaming 
agreement will receive alert messages on the roamed upon network if the operator of the roamed 
upon network is a Participating CMS provider and the subscriber's mobile device is configured 
for and technically capable of receiving alert messages from the roamed upon network; 



For purposes of section 602 of the Warning, Alert and Response Network (WARN) Act, Congress specifically 
defined "commercial mobile service" as that found in section 332(d)(1) of the Communications Act of 1934, as 
amended, 47 U.S.C. § 332(d)(1) (the term "commercial mobile service" means any mobile service that is provided 
for profit and makes interconnected service available to the public or to such classes of eligible users as to be 
effectively available to a substantial portion of the public, as specified by regulation by the Commission). Warning, 
Alert, and Response Network Act, Title VI of the Security and Accountability for Every Port Act of 2006, Pub. L. 
No. 109-347, 120 Stat. 1884, (2006), Titles I through III of the Communications Act of 1934, as amended, and 
Executive Order 13407 of June 26, 2006, Public Alert and Warning System, 71 Fed. Reg. 36975 (June 26, 2006) 
(WARN Act), § 602(b)(1)(A) (Executive Order 13407). 

2 WARN Act, § 602(a). 
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• Preemption of calls in progress: CM AS alerts may not preempt a voice or data session in 
progress; 

• Initial implementation: Participating CMS Providers must comply with these rules no later than 
10 months from the date the FCC announces the selection of a Federal Government entity to 
perform the Alert Aggregator and Alert Gateway functions required to implement the CM AS. 

3. In adopting these rules today, we take a significant step towards implementing one of our 
highest priorities - to ensure that all Americans have the capability to receive timely and accurate alerts, 
warnings and critical information regarding disasters and other emergencies irrespective of what 
communications technologies they use. As we have learned from disasters such as the 2005 hurricanes, 
such a capability is essential to enable Americans to take appropriate action to protect their families and 
themselves from loss of life or serious injury. This CMAS First Report and Order also is consistent with 
our obligation under Executive Order 13407 3 to "adopt rules to ensure that communications systems have 
the capacity to transmit alerts and warnings to the public as part of the public alert and warning system," 4 
and our mandate under the Communications Act to promote the safety of life and property through the 
use of wire and radio communication. 5 

4. This CMAS First Report and Order is the latest step of our ongoing drive to enhance the 
reliability, resiliency, and security of emergency alerts to the public by requiring that alerts be distributed 
over diverse communications platforms. In the 2005 EAS First Report and Order, we expanded the scope 
of the Emergency Alert System (EAS) from analog television and radio to include participation by digital 
television broadcasters, digital cable television providers, digital broadcast radio, Digital Audio Radio 
Service (DARS), and Direct Broadcast Satellite (DBS) systems. 6 As we noted in the Further Notice of 
Proposed Rulemaking that accompanied the EAS First Report and Order, wireless services are becoming 
equal to television and radio as an avenue to reach the American public quickly and efficiently. 7 As of 
June 2007, approximately 243 million Americans subscribed to wireless services. 8 Wireless service has 
progressed beyond voice communications and now provides subscribers with access to a wide range of 
information critical to their personal and business affairs. In times of emergency, Americans increasingly 
rely on wireless telecommunications services and devices to receive and retrieve critical, time-sensitive 
information. A comprehensive wireless mobile alerting system would have the ability to alert people on 
the go in a short timeframe, even where they do not have access to broadcast radio or television or other 
sources of emergency information. Providing critical alert information via wireless devices will 
ultimately help the public avoid danger or respond more quickly in the face of crisis, and thereby save 
lives and property. 



3 Public Alert and Warning System, Exec. Order No. 13407, 71 Fed. Reg. 36975 (Jun. 26, 2006) (Executive Order 
13407). In Executive Order 13407, the President noted that it was the "policy of the United States to have an 
effective, reliable, integrated, flexible, and comprehensive system to alert and warn the American people in 
situations of war, terrorist attack, natural disaster, or other hazards to public safety and well-being . . .," and 
established certain obligations in this regard for the Department of Homeland Security, the National Oceanic & 
Atmospheric Administration (NOAA), and the FCC. 

4 Executive Order 13407, § 3(b)(iii). 

5 See 47 U.S.C. § 151. 

6 See, e.g., Review of the Emergency Alert System, EB Docket No. 04-296, First Report and Order, 20 FCC Red 
18625 (2005) (EAS First Report and Order and Further Notice) 

1 Idat 18625, 18653. 

g 

Cellular Telecommunications & Internet Association, Mid- Year 2007 Top-Line Survey Results, available at 
http://files.ctia.org/pdf/CTIA Survey Mid Year 2007.pdf (last visited on Mar. 18, 2008). 
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H. BACKGROUND 

5. On October 13, 2006, the President signed the Security and Accountability For Every 
Port (SAFE Port) Act into law. 9 Title VI of the SAFE Port Act, the Warning Alert and Response 
Network (WARN) Act, establishes a process for the creation of the CMAS whereby CMS providers may 
elect to transmit emergency alerts to their subscribers. The WARN Act requires that we undertake a 
series of actions to accomplish that goal, including requiring the Commission, by December 12, 2006 
(within 60 days of enactment), to establish and convene an advisory committee to recommend system 
critical protocols and technical capabilities for the CMAS. 10 Accordingly, we formed the CMSAAC, 
which had its first meeting on December 12, 2006. 11 The WARN Act further required the CMSAAC to 
submit its recommendations to the Commission by October 12, 2007 (one year after enactment). 12 The 
CMSAAC submitted its report to us on that date. 13 

6. Section 602(a) of the WARN Act further requires that, by April 9, 2008 (within 180 days 
of receipt of the CMSAAC's recommendations), the Commission complete a proceeding to adopt 
"relevant technical standards, protocols, procedures and technical requirements" based on 
recommendations submitted by the CMSAAC, "necessary to enable commercial mobile service alerting 
capability for commercial mobile service providers that voluntarily elect to transmit emergency alerts." 14 
On December 14, 2007, we released the Notice of Proposed Rulemaking 15 requesting comment on, 
among other things, the technical requirements we should adopt to facilitate CMS providers' voluntary 
transmission of emergency alerts. 16 We specifically invited comment on the CMSAAC's proposed 
technical requirements. Comments were due on February 4, 2008, with Reply Comments due on 
February 19, 2008. 17 



See supra, n.l. 

10 WARN Act, § 603(a), (d). 

11 As required by the WARN Act, the CMSAAC consisted of representatives from state and local governments, 
federally recognized Indian tribes, representatives of the communications industry, including both wireless service 
providers and broadcasters, vendors and manufacturers and national organizations representing people with special 
needs. The Committee also included other qualified stakeholders such as representatives of the Federal Emergency 
Management Agency (FEMA) and NOAA. See Notice of Appointment of Members to the Commercial Mobile 
Service Alert Advisory Committee; Agenda for December 12, 2006 Meeting, Public Notice, 21FCC Red 14175 
(PSHSB 2006). 

12 WARN Act, § 603(c). 

13 

The CMSAAC held six meetings during which it received progress reports from its internal working groups and 
presentations from interested parties. On October 3, 2007, the Committee approved a set of recommendations and 
submitted them on October 12, 2007. In developing its recommendations, the CMSAAC consulted the National 
Institute of Standards and Technology (NIST), as required by section 603(g) of the WARN Act. 

14 WARN Act, § 602(a). 

15 The Commercial Mobile Alert System, PS Docket No. 07-287, Notice of Proposed Rulemaking, 22 FCC Red 
21975 (2007) (CMAS NPRM). 

16 In the CMAS NPRM, we also sought comment on issues related to other provisions of the WARN Act such as 
section 602(b) (requiring, among other things, that the Commission establish a mechanism for CMS providers to 
elect to participate in CMAS); section 602(c) (requiring the Commission to require noncommercial educational 
(NCE) broadcasters to install equipment to support geographically targeted (geo-targeting) alerts by CMS providers) 
and section 602(f) (authorizing the Commission to require testing of the CMAS). We will address these provisions 
of the WARN Act and related issues in subsequent Orders within the deadlines established by the statute. See 
CMAS NPRM, 22 FCC Red at 21976-21978, f 5. 

17 

A list of the parties commenting on the CMAS NPRM is attached at Appendix A. 
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III. DISCUSSION 

7. Consistent with section 602(a) of the WARN Act, today we adopt 'technical standards, 
protocols, procedures and other technical requirements . . . necessary to enable commercial mobile service 
alerting capability for commercial mobile service providers that voluntarily elect to transmit emergency 
alerts." 18 Specifically, the rules we adopt today address the CMS providers' functions within the CMAS, 
including CMS provider-controlled elements within the CMAS architecture, emergency alert formatting, 
classes and elements, geographic targeting (geo-targeting) and accessibility for people with disabilities 
and the elderly. 19 In most cases, we have adopted rules generally based on the CMSAAC 
recommendations. 20 In such cases, we find that the CMSAAC's recommendations are supported by the 
record and that adoption of those recommendations serves the public interest and meets the requirements 
of the WARN Act. For reasons discussed below, however, in some cases, we have determined that the 
public interest requires us to adopt requirements that are slightly different than those recommended by the 
CMSAAC. 

A. Consideration of the CMSAAC Recommendations 

8. Several entities representing the wireless industry generally argue in their comments that 
the Commission has no authority to adopt technical requirements other than those proposed by the 
CMSAAC and that those must be adopted "as is." 21 We disagree. The WARN Act does not require that 
we adopt the CMSAAC's recommendations verbatim. Rather, Congress required the Commission to 
adopt relevant technical requirements "based on recommendations of the CMSAAC." 22 This indicates 
that while Congress intended that we give appropriate weight to the CMSAAC's recommendations in our 
adoption of rules, it did not intend to require the Commission to adopt the CMSAAC's recommendations 
wholesale, without any consideration for views expressed by other stakeholders in the proceeding or the 
need to address other significant policy goals. 23 Moreover, adopting the CMSAAC's recommendations in 
their entirety, without scrutiny, would result in an abdication of the Commission's statutory mandate 
under the Communications Act to act in the public interest. Clearly the WARN Act did not delegate 
Commission authority under the Communications Act to an advisory committee; on the contrary, the 
Commission was to conclude a "proceeding" which necessarily implicates notice and an opportunity for 
public comment, and Commission discretion in adopting appropriate rules and requirements. 

9. Commission discretion and flexibility in its adoption of the CMSAAC recommendations 
is also supported by the policy goal underlying the WARN Act, i.e., the creation of a CMAS in which 
CMS providers will elect to participate, and which will effectively deliver alerts and warnings to the 
public. The comments of Ericsson, with which we agree, support Commission discretion by stating that 
the technical standards and requirements we adopt for the CMAS should account for an evolving 



WARN Act, § 602(a). 

19 As required by section 602(a) of the WARN Act, we consulted the NIST in our adoption of technical rules. 

20 

We note that the overwhelming majority of commenters support our adoption of the CMSAAC recommendations. 
See, e.g., T-Mobile Comments at 2, 3G America Comments at 11, CTIA Comments at 19, TIA Comments at 10, 
AT&T Comments at 20, Ericsson, Inc. (Ericsson) Comments at 6, Rural Cellular Association Comments at 1-2. 

21 

See, e.g., Verizon Wireless Comments at 6, Verizon Wireless Reply Comments at 2-3, Rural Cellular Association 
(RCA) Comments at 2-4, Alltel Comments at 2. 

22 See WARN Act, § 602(a). 

23 

Had Congress, as some commenters suggest, intended to require that the Commission adopt the CMSAAC's 
recommendations "as is," Congress would have simply said so. Moreover, the commenters' reading of the statute 
appears inconsistent with Congress' direction that both the CMSAAC and the Commission, separately, consult 
NIST. Cf, WARN Act § 602(a) and § 603(g). There would have been no need for the Commission to consult NIST 
again if, as the commenters suggest, Congress intended the Commission to simply adopt the CMSAAC's 
recommendations "as is." 
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technology landscape." In order to account for changes in the wireless industry and maintain a 
technologically neutral approach to emergency alerting, the Commission must be able to apply the 
CMSAAC's recommendations to new technologies and services. A reasonable interpretation of the 
WARN Act, therefore, is that the Commission has the discretion to evaluate the CMAS technical 
requirements recommended by the CMS A AC. 

B. CMAS Architecture and CMS Provider Functions 

10. In its recommendations, the CMSAAC proposed the following architecture for the 
CMAS. 25 



Functional Reference Model Diagram 




Under this proposed reference model, a Federal government entity, the "Alert Aggregator," operating 
under a "Trust Model," 26 would receive, aggregate, and authenticate alerts originated by authorized alert 
initiators (i.e., Federal, state, tribal and local government agencies) using the Common Alerting Protocol 
(CAP). 27 The Federal government entity would also act as an "Alert Gateway" 28 that would formulate a 
90 character alert based on key fields in the CAP alert sent by the alert initiator. 29 Based on CMS 
provider profiles maintained in the Alert Gateway, the Alert Gateway would then deliver the alert over a 



Ericsson Comments at 5. 

25 See CMSAAC recommendations, § 2.1, figure2-l (CMAS Functional Reference Model). 

26 See CMSAAC recommendations, § 8. 

27 

The Common Alerting Protocol (CAP) refers to Organization for the Advancement of Structured Information 
Standards (OASIS) Standard CAP- VI. 1, October 2005. 

28 See CMSAAC recommendations, § 2.2.4 

29 

Provisions have also been made for authorized alert originators to formulate and distribute alerts via the Alert 
Gateway in free text. See e.g., CMSAAC recommendations, § 5.3.2,. 
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secure interface operated by the CMS provider to another gateway maintained by the appropriate CMS 
provider (CMS Provider Gateway). 31 Each individual CMS Provider Gateway would be responsible for 
the management of the particular CMS provider elections to deliver alerts. The CMS Provider Gateway 
would also be responsible for formulating the alert in a manner consistent with the individual CMS 
provider's available delivery technologies, mapping the alert to the associated set of cell sites/paging 
transceivers, and handling congestion within the CMS provider infrastructure. Ultimately, the alert 
would be received on a customer's mobile device. The major functions of the mobile device would be to 
authenticate interactions with the CMS provider infrastructure, to monitor for CMAS alerts, to maintain 
customer options (such as the subscriber's opt-out selections), and to activate the associated visual, 
audio, and mechanical (e.g., vibration) indicators that the subscriber has indicated as options when an 
alert is received on the mobile device. 32 As part of its recommended model, the CMSAAC also 
proposed technical standards defining the functions of the Alert Aggregator, Alert Gateway, CMS 
Provider Gateway, CMS infrastructure, CMS handsets and various interfaces (i.e., A, B, C, D and E 
interfaces). 33 

11. In the CMAS NPRM, we sought comment on the CMSAAC s proposed reference 
architecture, including its standards for defining the various element functions. 34 Although most 
commenters supported the CMSAAC's proposal, a few objected to the CMSAAC's recommendation 
concerning the government-administered Alert Aggregator and an Alert Gateway. The Association of 
Public Television Stations (APTS) suggested that the Commission's role under the WARN Act is limited 
to adopting protocols to enable mobile services to opt into the Digital Emergency Alert System 
(DEAS). 35 CellCast asserted that a national Aggregator/Gateway is not required for CMAS 
implementation and that there are multiple models for alert distribution that do not use such an element. 36 
DataFM and the National Association of Broadcasters (NAB) raised concerns that a national aggregator 
would create a single point of failure that would reduce CMAS resiliency and/or introduce unacceptable 
performance degradation. 37 

12. According to the CMSAAC, a key element to CMS providers' ability to participate in the 
CMAS is the assumption of the Alert Aggregator and Alert Gateway functions by a Designated Federal 



See CMSAAC recommendations, § 2.3.1. 

31 See CMSAAC recommendations, § 2.3.2. 

32 See CMSAAC recommendations, § 2.3.5. 

33 

Each interface in the CMSAAC Reference Architecture represents a place where two elements in the Reference 
Architecture meet or connect. The "A" interface represents that connection between the alert initiator and the Alert 
Aggregator, the "B" interface represents the connection between the Alert Aggregator and Alert Gateway, the "C" 
interface represent the connection between the Alert Gateway and the CMS Provider Gateway, the "D" interface 
represents the connection between the CMS Provider Gateway and the CMS provider infrastructure, and the "E" 
interface represents the connection between the CMS provider infrastructure and the mobile device. For the 
purposes of this Order, the most important interfaces are the "C" and "E" interfaces. The "C" interface requires 
common protocols that will ensure that the alert information that flows from the Federal government administered 
Alert Gateway and the CMS providers is secure and accurate. Accordingly, both the Alert Gateway and CMS 
Provider Gateway must operate under a common set of protocols. The "E" interface will determine what 
information will appear on the mobile device. It is essential that the requirements for this interface allow accurate, 
timely, and accessible alerts for the mobile device user. 

34 See CMAS NPRM, 22 FCC Red at 21979-80, ff 12-13. 

35 

See APTS Comments at 2-3. The Digital Emergency Alert System (DEAS) is a next generation alert and warning 
system that leverages the transition of television to DTV format. 

36 See CellCast Comments at 24. 

37 DataFM Comments at 10, NAB Comments at 2-3. 
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Government Entity. Specifically, the CMSAAC recommended that the CMAS channel all Commercial 
Mobile Alert Messages (CMAMs) submitted by Federal, State, Tribal and local originators through a 
secure, Federal government administered, CAP-based alerting framework that would aggregate and hand 
off authenticated CMAMs to CMS Provider Gateways. 39 We sought comment on this recommendation in 
the CMAS NPRM. 40 The overwhelming majority of commenting parties supported the CMSAAC's 
recommendation. 41 Most wireless carriers commenting on the issue stressed that this was essential to 
CMS providers' participation in the CMAS. ALLTEL, for example, stated that if "a federal government 
entity does not assume these roles, wireless service providers are less likely to participate" in the CMAS 
because "in an emergency situation it is imperative that wireless service providers are able to rely on a 
single source . . . and government officials are more appropriately trained in authenticating and 

,,49 

constructing messages. 

13. We adopt the CMSAAC's proposed architecture for the CMAS. 43 We find that the 
recommended model will facilitate an effective and efficient means to transmit alerts and find that the 
public interest will be served as such. Contrary to APTS's assertions, nothing in section 602(a) of the 
WARN Act mandates that we only adopt requirements for CMS providers to opt into DEAS. 44 While we 
agree with CellCast that there are other potential models for alert delivery by electing CMS providers, we 
note that none of those alternative solutions received the support of the CMSAAC. Moreover, we note 
that the CMSAAC recommendation is the result of consensus among commercial wireless carriers and 
their vendors, public safety agencies, organizations representing broadcast stations and organizations 
representing people with disabilities and the elderly, and other emergency alert experts. This consensus 
was reached after approximately ten months of deliberation. No other party has suggested an alternative 
that would be superior in meeting the needs of the commercial wireless industry and in ensuring that 
alerts are received by electing CMS providers and then are transmitted to their subscribers. In fact, both 
during the CMSAAC deliberations as well as throughout this proceeding, many wireless carriers have 
indicated that the inclusion of an alert aggregator and alert gateway function is essential to their 
participation in the voluntary CMAS. 45 



38 

See CMSAAC recommendations, § 2.2. 

39 See CMSAAC recommendations, § 2.2.2 

40 CMAS NPRM, 22 FCC Red at 21979-80, ff 12-13. 

41 See generally, Alltel Communications LLC (Alltel) Comments at 4, AT&T Inc. (AT&T) Comments at 6, T- 
Mobile Comments at 7, and the California Public Utilities Commission (CAPUC) Comments at 6,7. But see, e.g., 
Ken Post Comments at 2 (CMAS should be based on a shred authority system as envisioned by the National 
Incident Management System), National Association of Broadcasters (NAB) Comments at 2-3 (a government-run 
aggregator creates a complex single system that has the potential to be a single point of failure), CellCast Comments 
at 7-9 (aggregator is not required for CMAS implementation, either at the National, State, or local levels). 

42 Alltel Comments at 4. 

43 See CMSAAC recommendations, §§ 2.3.5 and 7. 

44 As noted, infra at ff 34-41 the CMSAAC recommendations and this First Report and Order consistently conclude 
that the requirements for the CMAS should be technologically neutral. APTS's arguments regarding equipment are 
more appropriately addressed in the order that addresses section 602(c) of the WARN Act. 

45 AT&T Comments at 6 ("it is critical to the success. . . that a single Government Entity serve as the alert aggregator 
and gateway. . . whether it assumes this role directly or via a third party contractor "); CTIA Comments at 2 
(Commission adoption of the CMSAAC recommendations as submitted will encourage the highest level of 
participation); T-Mobile Comments at 15, 16 (Centralization is key to the proper functioning of a CMAS, and that it 
must be managed by the federal government. Without the centralized system, participation at all these levels could 
result in chaos). 



8 



Federal Communications Commission 



FCC 08-99 



14. Finally, we disagree with the concerns raised by DataFM and NAB that a national 
aggregator would necessarily create a single point of failure. While the CMSAAC recommended a single 
logical aggregator/gateway function, we expect that these functions will be implemented in a reliable and 
redundant fashion to maximize resiliency. 46 Furthermore, given the volume of alerts expected for the 
CM AS, we believe that technology for processing alerts will not place a constraint on aggregator/gateway 
performance. 47 Accordingly, we adopt the architecture proposed by the CMSAAC. As described below, 
however, we adopt as rules only those CMAS elements within the control of the CMS providers. 

15. Federal Government Role. We agree with the CMSAAC and the majority of commenters 
that a Federally administered aggregator/gateway is a necessary element of a functioning CMAS. While 
no Federal agency has yet been identified to assume these two functions, 48 we believe that a Federal 
government aggregator/gateway would offer the CMS providers the best possibility for the secure, 
accurate and manageable source of CMAS alerts that the WARN Act contemplates. 

16. We believe that FEMA, some other entity within DHS, or NOAA may be in the best 
position to perform these functions. 49 DHS, and more specifically FEMA, traditionally has been 
responsible for origination of Presidential alerts and administration of the EAS. 50 Moreover, Executive 
Order 13407 gives DHS primary responsibility for implementing the United States' policy "to have an 
effective, reliable, integrated, flexible and comprehensive system to alert and warn the American people 
in situations of war, terrorist attack, natural disaster or other hazards to public safety and well-being." 51 
By the same token, the Department of Commerce, and more specifically NOAA Weather Radio, as the 
"All Hazards" radio network, acts as the source for weather and emergency information, including natural 



See CMSAAC recommendations at 71. The CMSAAC recommended that CMAS system reliability meet 
"telecom standards for highly reliable systems," which generally implies the use of redundant elements where single 
points of failure would otherwise exist. 

47 Based on the CMAS alert volumes anticipated by the CMSAAC in section 1 1 of the CMSAAC recommendations, 
we agree with the CMSAAC s view that developing the technology for processing alerts according to the CMSAAC 
proposed timeline will not overburden the aggregator/gateway performance. 

48 

See FEMA Comments at 2 (stating that although it supports the CMSAAC's recommendations, it "[do[es] not 
have the authority during non-emergency periods to develop, implement, operate or maintain elements of the CMAS 
that regard alerts, warnings or notifications originated by state and local authorities such as the Aggregator and 
Gateway functions of the Trust Model of the CMAS, under [its] current statutory authority.") 

49 FEMA administers the Emergency Alert System (EAS) while NOAA operates the NOAA Weather Radio (NWR). 
See http ://w ww. weather. gov/nwr/ (last viewed on April 7, 2008). The respective roles of the Commission, FEMA, 
and NOAA are based on a 1981 Memorandum of Understanding, see State and Local Emergency Broadcasting 
System (EBS) Memorandum of Understanding Among the Federal Emergency Management Agency (FEMA), 
Federal Communications Commission (Commission), and the National Oceanic and Atmospheric Administration 
(NOAA) (Approved by National Industry Advisory Committee (NIAC) on April 21, 1982), a 1984 Executive Order, 
Assignment of National Security and Emergency Preparedness Telecommunications Functions, Exec. Order No. 
12,472, 49 Fed. Reg. 13,471 (1984), and a 1995 Presidential Statement of Requirements, see Presidential 
Communications with the General Public During Periods of National Emergency, The White House (September 15, 
1995). 

50 While the FCC could perform this role, additional funding to support such an undertaking would likely be 
necessary. We note that unlike the FCC, DHS and the Department of Commerce have authority under the WARN 
Act to borrow up to $106 million against Digital Television (DTV) transition revenues in order to fulfill their 
obligations under the statute. See WARN Act, § 606(c). It is also our understanding that FEMA has funding for its 
Integrated Public Alert and Warning System. 

51 Executive Order 13407, § 1. 
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(such as earthquakes or avalanches), environmental (such as chemical releases or oil spills), and public 
safety (such as AMBER alerts or 91 1) warning information. 52 

17. FEMA also played an integral role in the development of the CMSAAC's 
recommendations. FEMA chaired the Alert Interface Group (AIG), which was responsible for addressing 
issues at the front-end of the CMAS architecture (e.g., receipt and aggregation of alerts, development of 
trust model to authenticate alerts from various sources). It also represented the AIG before the CMSAAC 
Project Management Group (PMG), which coordinated the work of all the other CMSAAC working 
groups and assembled the CMSAAC recommendations document. In addition, FEMA voted to adopt the 
CMSAAC recommendations in October 2007, which included CMAS reliance on a single Federal 
authority to fulfill the gateway /aggregator role. 

18. We recognize that FEMA asserted in its February 2008 comments that limits on its 
statutory authority preclude the agency from fulfilling the Federal aggregator/gateway functions. 53 
Nevertheless, timely identification of a federal agency capable of fulfilling the aggregator/gateway 
functions recommended by the CMSAAC is essential to bringing the concrete public safety benefits of a 
CMAS system to the American people. 54 We are hopeful that any bars that prevent FEMA or some other 
entity within DHS from fulfilling these roles will be lifted expeditiously. We will work with our Federal 
partners and Congress, if necessary, to identify an appropriate government entity to fulfill these roles, 
whether that is FEMA, another DHS entity, NOAA or the FCC. 

19. Scope of Order. Accordingly for purposes of this Order, we proceed on the assumption 
that a Federal agency will assume these roles at a future date. Today's Order is limited to adopting rules 
governing those sections of the CMAS architecture that are within the control of electing CMS 
providers. 55 These include rules regarding the CMS Provider Gateway, CMS provider infrastructure, and 
CMS provider handsets. Specifically, we adopt rules, based on the CMSAAC's recommendations, that 
require each individual CMS Provider Gateway to be able to receive alerts from the Federal government 
alert gateway over a secure interface (i.e., "C Interface"). 56 The CMS Provider Gateway will be required 
to, among other things: (1) manage the CMS provider's election to provide alerts; (2) format alerts 



~ FEMA administers the Emergency Alert System (EAS) while NOAA operates the NOAA Weather Radio (NWR). 
See http ://www . we ather . go v/nwr/ (last viewed on April 7, 2008). The respective roles of the Commission, FEMA, 
and NOAA are based on a 1981 Memorandum of Understanding, see State and Local Emergency Broadcasting 
System (EBS) Memorandum of Understanding Among the Federal Emergency Management Agency (FEMA), 
Federal Communications Commission (Commission), and the National Oceanic and Atmospheric Administration 
(NOAA) (Approved by National Industry Advisory Committee (NIAC) on April 21, 1982), a 1984 Executive Order, 
Assignment of National Security and Emergency Preparedness Telecommunications Functions, Exec. Order No. 
12,472, 49 Fed. Reg. 13,471 (1984), and a 1995 Presidential Statement of Requirements, see Presidential 
Communications with the General Public During Periods of National Emergency, The White House (September 15, 
1995). 

53 See FEMA Comments at 2. 

54 Accordingly, the compliance date for the rules we adopt today is tied to the announcement of an entity to fulfill 
these functions. The absence of an aggregator/gateway, however, will have no impact on a CMS provider's 
obligation under the WARN Act to elect whether or not it intends to transmit emergency alerts within 30 days of the 
Commission's issuance of rules required under section 602(b). See WARN Act, § 602(b). 

55 A complete list of the required CMS infrastructure functions is set forth in the rules in Appendix C. 

56 The C interface is a secure interface over which alerts can be passed from the Aggregator/Gateway to the CMS 
Provider Gateway. Under our rules, the CMS provider must: (1) provide information for the authentication and 
validation of actions across the interface; (2) be able to receive new, updated or cancelled wireless alert messages 
from the Alert Gateway in a format that is suitable for the mobile devices and the wireless alert deliver technology 
or technologies implemented by the CMS provider; and (3) acknowledge the receipt of new, updated or cancelled 
wireless alert messages. 
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received in a manner consistent with the CMS provider's available delivery technology; (3) map alerts to 
the associated set of cell sites/paging transceivers; and (4) manage congestion within the CMS provider's 
infrastructure. 57 In addition, we adopt rules, based on the CMSAAC's recommendations, requiring the 
CMS infrastructure to, among other things: (1) authenticate interactions with the mobile device; (2) 
distribute received CMAS alert messages to the appropriate set of cell sites/paging transceivers for 
transmission to the mobile device; and (3) transmit the CMAS alert message for each specified cell 
site/pager transceiver. 58 

20. We adopt the CMSAAC's recommendations regarding capabilities of the mobile device 
including that it: (1) authenticate interactions with the CMS provider infrastructure; (2) maintain 
configuration of CMAS alert options; and (3) present received CMAS alert content to the subscriber. 59 In 
addition, as explained below, we adopt requirements for the mobile device to ensure that people with 
disabilities are able to receive CMAS alerts. 60 We also adopt the CMSAAC's recommendation that 
CMAS alerts not preempt ongoing voice or data sessions. 61 

21. In keeping with our policy to promote technological neutrality, we decline to adopt rules 
governing the communications protocols that the CMS providers must employ for communications across 
the D or E interfaces as identified in the architecture. 62 We agree with the CMSAAC that no specific 
protocols should be required for the D and E interface, but rather that CMS providers should be allowed 
to retain the discretion to define these protocols in conjunction with their overall network design and with 
the mobile device vendors. 63 Both of these interfaces lie entirely within the control of the CMS providers 
and any implementation decisions there will have no impact on CMAS ability to satisfy the system 
requirements we set forth elsewhere in this Order. 64 For example, while we do include requirements on 
the type of alert information that must cross the D and E interfaces to enable CMAS alerts on mobile 
devices, we choose to remain silent as to the precise communications protocol that a CMS provider uses 
to convey this information to the mobile device. 65 This approach gives the CMS providers maximum 
flexibility to leverage technological innovation and implement the CMAS in a cost effective manner. 

22. We also adopt rules requiring, per the CMSAAC's recommendation, that electing CMS 
providers assemble individual profile information to provide to the Authorized Federal Government 
Entity, once that entity is identified. 66 We believe that electing CMS providers expect to assemble this 



A complete list of the CMS Provider Gateway's required functions is set forth in the rules in Appendix C. 

58 

Interstate Wireless supports the CMSAAC recommended reference architecture, but notes that the cost of building 
and maintaining a CMS Provider Gateway would be more than it and other similarly situated Small Business CMS 
providers could afford and still be able to provide the alert service to the public without cost. Accordingly, Interstate 
Wireless requests that the Federal Government either provide the proper software and reception equipment for the 
CMS Provider Gateways, or provide grants to the Small Business CMS providers to purchase, install, and maintain 
the equipment themselves. Interstate Wireless Comments at 6. We acknowledge the concern of Interstate Wireless, 
but note that questions of funding are not addressed by section 602(a) of the WARN Act, and thus are outside of the 
scope of this order. 

59 CMSAAC recommendations, § 1.1.1. 

60 See infra ff 57-67. 

61 CMSAAC recommendations, § 7.3. 

62 See Functional Reference Model Diagram, supra f 10. 

63 No commenter objected to this recommendation. 

64 For this reason, we conclude that our decision is consistent with section 602(a) of the WARN Act which requires 
that we adopt technical requirements "necessary" for CMS alerting capability. WARN Act, § 602(a). 

65 See infra, ff 26-30 (discussion of CMAS Alert Categories). 

66 See CMSAAC recommendations, § 2.2.4.2. 
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information, and by adopting this requirement now, we are providing direction to potential Alert Gateway 
providers. 67 

23. The CMSAAC recommended detailed technical protocols and specifications for the Alert 
Aggregator/Gateway entity and the CMS providers to employ for the delivery of alerts over the various 
interfaces (i.e., A, B and C interfaces) in the Reference Model. Specifically, section 10 of the CMSAAC 
recommendations proposed requirements that Alert Initiators must meet to deliver CMAS alerts to the 
Alert Aggregator, and that the Alert Gateway must meet to deliver CMAS alerts to the CMS Provider 
Gateway. 68 The CMSAAC also recommended CAP-based mapping parameters. 

24. We support the technical protocols and specifications for the delivery of alerts 
recommended by the CMSAAC in this section. Electing CMS providers could use these technical 
protocols and specifications to design their internal systems that would enable compliance with the rules 
we adopt in this docket. We decline, however, to codify these protocols and specifications in this Order. 
We believe that these protocols offer a significant guidance to CMAS participants as they further develop 
the final protocols and interface for the CMAS, but until an Alert Aggregator/Gateway entity is 
determined, additional refinements and revisions of these protocols and specifications are inevitable. 
Accordingly, we conclude that final determination of these interface protocols is better left to industry 
standards organizations. 69 We will revisit this matter in the future if Commission action in this area is 
indicated. 

C. General CMAS Requirements 

25. In this section, we establish the basic regulatory framework of the new CMAS. 
Specifically, we adopt technologically neutral rules that address, among other things, the scope of CMAS 
alerts, geo-targeting and alert accessibility for people with disabilities and the elderly. 

1. Scope and Definition of CMAS Alerts 

26. The WARN Act requires the Commission to enable commercial mobile alerting 
capabilities for "emergency" alerts, 70 but does not define what may comprise an emergency. 
Accordingly, in the CMAS NPRM, we sought comment on the appropriate scope of emergency alerts, 
including whether and to what extent alerts should be classified. 71 We specifically asked parties to 
address whether we should implement the CMSAAC s recommendation to specify three alert classes: (1) 
Presidential Alert; (2) Imminent Threat Alert; and (3) Child Abduction Emergency or AMBER Alert. 72 
For the reasons stated below, we find that the public interest will be best served by our adopting these 
three alert classes, and we define them below. 

27. We agree with the majority of commenters that the three classes of alert recommended by 
the CMSAAC achieves the best balance between warning of imminent threat to life and property with the 
current technical limits that CMS provider systems face in delivering timely, accurate alerts. 73 Alert 



See CMSAAC recommendations, § 2.2.4.2 and Table 2. 1 . 

68 See CMSAAC recommendations, § 10. 

69 We note that the Alliance for Telecommunications Industry Solutions (ATIS) and Telecommunications Industry 
Association (TIA) are beginning to engage in standards setting related to the CMAS. See ATIS Comments at 4-5. 

70 WARN Act, § 602(b)(2)(e). 

71 CMAS NPRM, 22 FCC Red at 21981, 116. 

72 Id. 

73 CMSAAC recommendations at § 5.1. See also CAPUC Comments at 10-11. 
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Systems however argues that we should include additional classes of alerts, such as traffic advisories. 
We find that inclusion of such alerts would be inconsistent with the intent of Congress, expressed 
throughout the WARN Act, that the Commission enable an "emergency" alerting system. We believe that 
if the public were to receive commercial mobile alerts that do not relate to bona fide emergencies, there 
would be a serious risk that the public would disregard mobile alerts or possibly opt not to receive 
anything but Presidential alerts. 75 We also note that, given the current technical capabilities of CMS 
providers to deliver emergency alerts, it is possible that if too many alerts are injected into a CMS 
provider's system in a very brief period, vital messages could be delayed. Accordingly, we reject 
arguments to broadly define eligible alert classes beyond those specified here. 

a. Presidential Alerts 

28. Section 602(b)(2)(E) of the WARN Act authorizes participating CMS providers to allow 
device users to prevent the receipt of alerts or classes of alerts "other than an alert issued by the 
President." 76 Congress thus intended to afford Presidential Alerts the highest priority. Affording 
Presidential Alerts the highest priority also will enable the Secretary of Homeland Security to meet 
his/her obligation, under Executive Order 13407, to "ensure that under all conditions the President of the 
United States can alert and warn the American people." 77 Accordingly, electing CMS providers must 
transmit such alerts and assign the highest priority to any alert issued by the President or the President' s 
authorized designee. 78 Further, Presidential Alerts must be transmitted upon receipt by a CMS provider, 
without any delay, and therefore will preempt any other pending alert. We note that due to the initial 90- 
character text message protocol that we are adopting below for the first generation CM AS, 79 it is possible 
that a Presidential Alert may direct recipients to other sources, possibly taking the form recommended by 
the CMSAAC: "The President has issued an Emergency Alert. Check local media for more details." 80 

b. Imminent Threat Alerts 

29. We note that virtually all commenting parties support adoption of the CMSAAC 's 
recommendation to define an Imminent Threat Alert class. 81 This alert class is narrowly tailored to those 
emergencies where life or property is at risk, the event is likely to occur, and some responsive action 
should be taken. Specifically, an Imminent Threat Alert must meet separate thresholds regarding 
urgency, severity, and certainty. Each threshold has two permissible CAP values. 

• Urgency. The CAP "urgency" element must be either Immediate (i.e., responsive action 
should be taken immediately) or Expected (i.e., responsive action should be taken soon, 
within the next hour). 82 

• Severity. The CAP "severity" element must be either Extreme (i.e., an extraordinary threat to 



Alert Systems Comments at 16 (urging more than three classification levels, claiming disaster managers need the 
ability to dispatch road closure and other community relevant information). 

75 

See MetroPCS Comments at 3 (noting that if too many alert messages are transmitted, users may ignore them); T- 
Mobile Comments at 10 ("[subscribers will be more likely to opt out of CMAS altogether if their devices are 
inundated with minor alerts"). 

76 WARN Act, § 602(b)(2)(e). 

77 

Executive Order 13407, § 2(a)(x). 

78 

See CMSAAC recommendations, § 2.3.2 (CMS providers will prioritize Presidential alerts). 

79 See infra I f 82-83. 

80 CMSAAC recommendations, § 5.3.3. 

8 1 

But cf. CellCast Comments at 29 (opposing adoption of alert classes). 
82 See CAP-V1.1 at 16. 
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life or property) or Severe (i.e., a significant threat to life or property). 

• Certainty. The CAP "certainty" element must be either Observed (i.e., determined to have 
occurred or to be ongoing) or Likely (i.e., has a probability of greater than fifty percent). 84 
That is, the event must have occurred, or be occurring (Observed), or be more likely to occur 
than not (Likely). 

30. We find that the transmission of these imminent threat alerts is essential to a useful 
CM AS. The CMSAAC recommended such action and the commenting parties overwhelmingly support 
this conclusion. 85 As T-Mobile correctly states, CMAS alerts are not appropriate for warning the public 
about minor events. 86 Subscribers are more likely to opt out if they are bombarded by minor notices, and 
may fail to notice a truly serious alert. Also, inclusion of minor events would be an unnecessary burden 
on the CMS provider infrastructure. Accordingly, we find it appropriate to require participating CMS 
providers to transmit Imminent Threat Alerts. 

c. Child Abduction Emergency/AMBER Alerts 

31. There is broad support in the record for adoption of the CMSAAC 's recommendation to 
specify a third alert class, Child Abduction Emergency or AMBER Alert. 87 There are four types of 
AMBER Alerts: (1) Family Abduction, 88 (2) Nonfamily Abduction, 89 (3) Lost, Injured, or Otherwise 
Missing, 90 and Endangered Runaway. 91 AMBER plans are voluntary partnerships between law 
enforcement agencies, broadcasters and CMS providers to activate an urgent bulletin in the most serious 
child abduction cases, and AMBER alerts are issued only where an AMBER plan has been duly 
established. 92 We also note that a number of CMS providers currently transmit AMBER Alerts using 



See CAP-V1.1 at 17. 



See supra, n.20. 
86 T-Mobile Comments at 9-10. 

87 

See, e.g., Acision Comments at 6-7 (supporting the inclusion of AMBER alerts to, among other things, maintain 
public awareness of the CMAS). We note that on April 30, 2003, President George W. Bush signed the 
Prosecutorial Remedies and Other Tools to end the Exploitation of Children Today (PROTECT) Act of 2003 (Pub. 
L. No. 108-21,1 17 Stat 650 (Apr. 20, 2003)) into law. Building on the steps already taken by the Federal 
Government to support AMBER Alerts, this Act codified the national coordination of state and local programs, 
including the development of guidance for issuance and dissemination of AMBER Alerts and the appointment of a 
national AMBER Alert Coordinator. 

88 

A Family Abduction (FA) involves an abductor who is a family member of the abducted child such as a parent, 
aunt, grandfather, or stepfather. See http://www.amberalert.gov/statistics.htm. 

89 

A Nonfamily Abduction (NFA) involves an abductor unrelated to the abducted child, either someone unknown to 
the child and/or the child's family or an acquaintance/friend of the child and/or the child's family. Id. 

90 A Lost, Injured, or Otherwise Missing (LIM) involves a case where the circumstances of the child's 
disappearance are unknown. Id. 

91 An Endangered Runaway (ERU) involves a missing child who is believed to have run away and in imminent 
danger. Id. 

92 

Localities generally establish AMBER plans based on the U.S. Department of Justice's five criteria that should be 
met before an alert is activated: (1) law enforcement confirms a child has been abducted; (2) the child is 17 years or 
younger; (3) law enforcement believes the child is in imminent danger of serious bodily harm or death; (4) there is 
enough descriptive information about the victim and the abduction to believe an immediate broadcast alert will help; 
and (5) the child's name and other data have been entered into the National Crime Information Center. See 
http ://w w w . amberalert . gov/ . 
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Short Message Service (SMS) technology, and we applaud their potentially life-saving efforts in this 
regard. 

32. In 2006, 261 AMBER Alerts were issued in the United States involving 316 children. 94 
Most of these alerts were issued on an intrastate basis. 95 Of the 261 AMBER Alerts issued in 2006, 214 
cases resulted in a recovery, 53 of which were resolved as a direct result of an AMBER Alert being 
issued. 96 Based on the limited number of AMBER alerts and their confined geographic scope, we do not 
expect such alerts to be overly burdensome to CMS providers that participate in the CMAS. Moreover, 
because of the efficacy of AMBER Alerts, we find that the public interest in the safety of America's 
children will be well served by the provision of AMBER Alerts by the wireless industry. Accordingly, 
we require participating CMS providers to transmit AMBER alerts. 

2. Technologically Neutral Alert System 

33. The CMSAAC recommended that CMS providers that elect to participate in the CMAS 
should "not be bound to use any specific vendor, technology, software, implementation, client, device, or 
third party agent, in order to meet [their] obligations under the WARN Act." 97 We agree. As 
SouthernLINC notes, participating CMS providers should be able to choose the technology that will allow 
them to best meet the emergency alerting needs of the American public. 98 Consistent with the 
Commission's well-established policy of technologically-neutral regulation of the wireless 
telecommunications industry, 99 we believe that CMS providers and equipment manufacturers are in the 
best position to select and incorporate the technologies that will enable them to most effectively and 
efficiently deliver mobile alerts. Accordingly, we will not limit the range of technologies that electing 
CMS providers may deploy to participate in the CMAS. In reaching this conclusion, we have balanced 
the alerting needs of the public and the capabilities of electing CMS providers and our mandate under 
section 602(a) of the WARN Act to enable the provision of emergency alerts. 100 We emphasize that the 
WARN Act does not require the establishment of any specific technology to be used for the CMAS. 

34. CMS providers are in various stages of readiness to participate in the CMAS. Paging 
carriers already provide point to multipoint services, using technologies such as ReFLEX and POCSAG 
(Post Office Code Standardization Advisory Group), to reach many subscribers at the same time and 
therefore appear well-positioned to participate in CMAS. 101 However, as the American Association of 



See How Wireless AMBER Alerts™ Are Sent, available at 
http://wirelessamberalerts.adcouncil.org/howwirelessamberalertswork.htm . 

94 See National Center for Missing & Exploited Children, 2006 AMBER-Alert Report at 7. 

95 In 2006, 1 1 AMBER Alerts were extended beyond the limits of the state where the alert first originated. Id. at 8. 
Eight alerts were extended to one additional state, and three alerts were extended to two states each. Id. 

96 Nine (9) children were recovered deceased, and, as of April 21, 2007, 10 cases remained active with 1 1 children 
still missing. Id. 

Q7 

CMS SAC recommendations, §5.1. 

98 SouthernLINC Comments at 4-6. 

99 See Amendment of the Commission's Rules to Permit Flexible Service Offerings in the Commercial Mobile Radio 
Services, WT Docket No. 96-6, Second Report and Order and Order on Reconsideration, 15 FCC Red 14680 
(2000). 

100 WARN Act, § 602(a). 

101 ReFLEX is a wireless network protocol developed by Motorola which is used for two-way paging. Narrowband 
PCS carriers use the ReFLEX technology protocol, which can transmit data at speeds ranging from 3.2 to 25 kbps. 
See Tenth CMRS Competition Report, 20 FCC Red at 15955, f 124. For more information regarding ReFLEX, see 
http://usamobility.com/pdf/ReFLEX2.pdf . For more information regarding POCSAG, see 
http://www.wireless.per.nl/reference/chaptr01/dtmmsyst/paging.htm. 
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Paging Carriers notes, it may not be feasible for paging carriers to confine their alerts to either county- 
wide or sub-county distribution. 102 Further, cellular, PCS, and SMR service providers, report that they 
have not deployed an emergency alerting capability that satisfies all requirements in the CMSAAC 
recommendations and that is currently available for the mass transmission of alerts. 103 We note that many 
of the requirements that we adopt today are intended to apply to a first generation text-based alerting 
service. Other service profiles, such as streaming audio and video, are in their early developmental stages 
and thus not ripe for implementation by the Commission. We foresee that as CMS providers gain 
experience with these and other alerting technologies, they may well be incorporated into future alerting 
system deployments. 

35. Although the CMSAAC found that point-to-point technologies may not be well suited for 
mass alerting, 104 we will not prohibit their use if a CMS provider can otherwise meet the requirements 
that we establish today. Short Message Service (SMS) 105 text messaging is available to most cellular, 
PCS, and SMR subscribers and is currently used by some municipalities and other local jurisdictions to 
provide emergency alerts on an opt-in basis. 106 We recognize, however, that SMS may not be a desirable 
solution for the widespread dissemination of alerts to the public because the mass delivery of SMS- 
formatted alerts could degrade network performance and delay alert delivery. Despite these potential 
drawbacks, SMS text messaging may offer a viable, short-term delivery method for electing CMS 
providers that do not yet have a point-to-multipoint text messaging capability. 107 

36. The CMSAAC noted that technologies such as MediaFLO and DVB-H "may provide 
supplemental alert information," 108 but recommended that they should not be considered as part of the 
CMAS. 109 Our goal in this proceeding is to enable the broadest possible voluntary participation in the 
CM AS, and we will not foreclose the possible deployment of these or other innovative technologies as a 
means of participating in the nascent CMAS. The public interest is best served by not circumscribing the 
range of technologies that CMS providers may elect to deploy to meet the alerting needs of the American 
public. 



See AAPC Comments at 7. 

103 See, e.g., Sprint Nextel Comments at 8-9 (noting that certain industry standardization processes must be 
completed before CMAS deployment). 

104 According to the CMSAAC, point-to-point technologies may experience delivery delays, network congestion, 
and lack geo-targeting capabilities because alerts are targeted to phone numbers instead of a specific alert area. See 
CMSAAC recommendations at § 5.2. 

105 SMS enables the transmission of alphanumeric messages between mobile subscribers and external systems such 
as electronic mail, paging, and voice mail systems. For a more complete description, see 
http://electronics.howstuffworks.com/smsl.htm and http://www.mobilein.com/SMS tutorial.pdf . 

106 The District of Columbia and many of its neighboring jurisdictions, for example, have such emergency alert 
systems. See http://textalert.ema.dc.gov (Alert DC); http : //w w w . f airf axcounty . go v/c e an (Fairfax County, VA); 
http://alert.montgomervcountymd.gov (Montgomery County, MD). 

107 

Many CMS providers are successfully using SMS today to transmit geographically specific AMBER Alerts to 
interested subscribers. The wireless AMBER alert system notifies wireless customers who have elected to receive 
the service of missing children alerts. Information regarding the system is available at 

http://www.wirelessfoundation.org/amber . Thirty-two wireless carriers currently participate in the system. See 
http ://wireles samberalerts . adcouncil. org/partners . htm . 

108 

CMSAAC recommendations, § 5.2. Information regarding MediaFLO technology is available at 
http://www.qualcomm.com/mediaflo/about us/index. shtml . Information regarding DVB-H technology is available 
at http:// www.dvb-h.org/technology.htm . 

109 CMSAAC recommendations, § 5.2. 
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37. Several parties express support for an FM-based CMAS solution such as that provided by 
ALERT-FM and Global Security Systems. 110 The CMSAAC however considered the costs and benefits 
of Radio Broadcast Data System (RBDS) and other FM-based alert and warning solutions, and found 
them to be infeasible for the CMAS. 111 Moreover, a number of parties have expressed reservations about 
these technologies. 1 12 Nonetheless, in keeping with our overall policy to maintain technological 
neutrality, we do not require or prohibit the use of ALERT-FM, RBDS or similar systems as the basis of 
the CMAS. 113 

38. We also strongly encourage fair, reasonable, and nondiscriminatory Intellectual Property 
Rights (IPR) licensing in the context of the CMAS. We agree with the CMSAAC that the technical 
standards, protocols, procedures, and related requirements that we adopt pursuant to section 602(a) of the 
WARN Act today should be standardized in industry bodies that have well defined IPR policies. 114 We 
decline, however, to compel all CMSAAC participants "to provide written assurance to the 
Commission that, if and insofar as one or more licenses may be required under any of their respective 
IPRs that are technically essential for purposes of implementing or deploying CMAS, the rights holders 
shall license such IPR on a fair, reasonable and nondiscriminatory basis for those limited purposes 
only." 115 We also decline to require "all participants in the public comment process on th[e] CMAS 
Architecture and Requirements document" to make such a written assurance. 116 These requests are 
outside the scope of section 602(a) of the WARN Act. 

39. The CMSAAC made a number of additional recommendations that we conclude are 
outside the scope of our mandate under section 602(a) of the WARN Act to adopt "technical standards, 
protocols, procedures, and other technical requirements," to enable voluntary commercial mobile 
alerting. 117 Specifically, the CMSAAC submitted recommendations regarding the applicability of 
requirements for location, number portability and the Communications Assistance for Law Enforcement 
Act (CALEA). 118 The CMSAAC also submitted recommendations on whether CMS providers may 
utilize the technical requirements adopted herein for other services and purposes and whether CMS 
providers may recover certain costs related to the development of the CMAS. 119 We find that these issues 
are outside the scope of section 602(a) of the WARN Act and, therefore, do not address these issues 
herein. 

40. The CMSAAC recommended that, to the extent practicable, "Federal, state, tribal, and 
local level CMAS alert messages [should] be supported using the same CMAS solution." 120 We agree. 
We believe that a uniform approach to implementation of the CMAS will be inherently more cost 



110 See, e.g., Comments of Data-FM at 7-8, Sheriff of Jefferson County, Louisiana; Florida Association of 
Broadcasters, Mississippi Office of Homeland Security, Mississippi Office of Emergency Management. 

111 See CMSAAC recommendations at 47-48. 

112 See e.g., AT&T Reply Comments at 11-12. 

113 

CMS providers have discretion to use these technologies so long as they are able to transmit emergency alerts in 
a manner consistent with the rules we adopt today. 

114 CMSAAC recommendations, § 5.1. 

115 Id. 

116 Id. 

117 WARN Act, § 602(a). 

118 CMSAAC recommendations, § 5.2.4. 

119 CMSAAC recommendations, § 5.1 

120 Id. 
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effective, more technologically consistent and thus more likely to facilitate participation by small and 
rural CMS providers. Further, we agree that electing CMS providers should not be required to support 
alerting on mobile handsets manufactured for sale to the public prior to a CMS provider's initiation of the 
CMAS alerting service. In a subsequent order, we will address how participating CMS providers may 
sell such non-compliant handsets consistent with the requirement under section 602(b) of the WARN Act 
that they disclose "at the point of sale of any devices with which its commercial mobile service is 
included, that it will not transmit such alerts via the service it provides for the device." 121 Finally, we 
agree that electing CMS providers should have discretion regarding whether certain devices, such as 
laptop wireless data cards, will support alerting capabilities. 

3. CMAS Message Elements and Capabilities 

a. Required Alert Message Elements 

41. The CMSAAC recommended that emergency alert messages follow the same general 
format of National Weather Service alert messages, subject to a 90-character text limitation. 122 
Specifically, the CMSAAC recommended that for initial CMAS deployments, messages should include 
five elements in the following order: 

• Event Type or Category 

• Area Affected 

• Recommended Action 

• Expiration Time (with time zone) 

• Sending Agency 

The CMSAAC proposed this format to facilitate CAP value field mapping to text. 123 It also noted that 
the format would likely evolve as experience is gained by alert initiators and by electing CMS 
providers. 124 In the CMAS NPRM, we sought comment on the five elements and asked parties to address 
whether the elements are consistent with accepted industry practices for emergency alerts. 125 

42. There is broad support in the record for standardization of alert messages and adoption of 
the five recommended message elements. T-Mobile explains that the format "is designed to ensure that 
the most critical information is succinctly and clearly communicated in a manner most compatible with 
the technical attributes of wireless networks." 126 Purple Tree Technologies also supports the five 
message elements, but urges that event type and area affected be the only required elements, with others 
optional if space permits. 127 Based on our review of the record, we find that on balance the five message 
elements identified above will enable standardization of alerting messages and we hereby adopt them. We 
reject Alert Systems' claim that the element for "area affected" should be reconsidered, based on its 
hypothesis that "visitors and newcomers to areas often do not recognize geographic landmarks in warning 
messages." 128 A biohazard or flash flood warning, for example, would not enable the public to avoid a 



WARN Act, § 602(b). 

CMSAAC recommendations, § 5.3.1. 

Id. 

Id. 

CMAS NPRM, 22 FCC Red at 21981, 118. 
T-Mobile Comments at 18. 
Purple Tree Technologies Comments at 10. 
Alert Systems Comments at 16-17. 
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lethal hazard without appropriate area affected information. We also expect that as CMAS providers 
eventually deploy technologies capable of messages of more than 90 characters, additional alert message 
elements will be implemented. 

43. In the CMAS NPRM, we also sought comment on whether alert messages should include 
telephone numbers, URLs 129 or other response and contact information, including any related network 
impacts. 130 The CMS AAC advised against inclusion of URLs or telephone numbers because such 
information would encourage mass access of wireless networks. 131 The California Public Utility 
Commission (CAPUC) supports inclusion of a sixth message element for URLs, if feasible. 132 AT&T 
(and many commenting parties) note that inclusion of a URL or telephone number in an emergency 
message, some of which might be delivered to tens of thousands of users in a matter of seconds, could 
lead to unacceptable network congestion and, in extreme cases, network failure. 133 We find that 
mandating URLs or telephone numbers in an emergency alert could exacerbate wireless network 
congestion at a time when network traffic is already dramatically increasing as individuals contact police, 
fire, and rescue personnel, as well as their loved ones. 134 We therefore will not require participating CMS 
providers to accept or transmit any alert message that contains an embedded URL or telephone number. 

b. CMAS Generation of Free Text Alert Messages 

44. In the CMAS NPRM, we sought comment on the CMSAAC's recommendation that the 
Alert Gateway automatically generate messages by extracting information from specified fields of a CAP- 
formatted message, SAME codes, or free-form text, which would then be transmitted across Reference 
Point C to electing CMS providers. 135 The CMSAAC recommended this approach for initial system 
deployments. 136 We also sought comment on the CMSAAC's recommendation to allow the generation of 
free text for Presidential and AMBER alert messages. 137 While numerous parties in this proceeding 
support adoption of the CMSAAC recommendations in full, few address the specific mechanics of 
generating alert messages via the Alert Gateway. 138 AT&T states that proposals for automatic generation 
of alert text "merit further investigation, but responsibility for the content of alerts should remain with 
initiators and the federal government — not wireless carriers." 139 We agree with AT&T and other parties 



URL is an acronym for Uniform Resource Locator and is a reference (an address) to a resource on the Internet. A 
URL has two main components: a protocol identifier and a resource name, which are separated by a colon and two 
forward slashes. The protocol identifier indicates the name of the protocol to be used to obtain the resource, such as 
HTTP (Hypertext Transfer Protocol). HTTP is just one of many protocols used to access different types of 
resources on the Internet. Other protocols include File Transfer Protocol (FTP), Gopher, File, and News. Additional 
information regarding URLs is available at http://iava.sun.com/docs/books/tutorial/networking/urls/index.html . 

130 CMAS NPRM, 22 FCC Red at 21981-82, f20. 

131 

See CMSAAC recommendations, § 5.3.2.1. 
132 See, e.g., CAPUC Comments at 12. 
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AT&T Comments at 8; T-Mobile Comments at 19-20 (opposing inclusion of URLs, telephone numbers because 
"such information could cause customers to flood the wireless network resulting in crippling network congestion)" 

134 See Alltel Reply Comments at 3 ("network congestion exists during emergencies today and would be made 
worse by inserting a phone number or URL to encourage people to initiate more calls'); RCA Reply Comments at 7 
(inclusion of URLs or telephone numbers could make "it difficult or impossible for anyone to complete a critical 
telephone call" and possibly "tak[e] the entire wireless network down"). 

135 CMAS NPRM, 22 FCC Red at 21981, f 19; CMSAAC recommendations, § 5.3.2. 

136 See CMSAAC recommendations, § 5.3.2. 

137 CMAS NPRM, 22 FCC Red at 21981, f 19; CMSAAC recommendations, § 5.3.3. 
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that electing CMS providers should act as a conduit for messages, the content of which is fixed before 
transmission to a CMS provider. 

45. CellCast argues that we should "ignore" the CMSAAC recommendations regarding alert 
generation, asserting that message generation is beyond our mandate under the WARN Act. 140 The 
mechanisms for generating messages at the Alert Gateway are undefined currently and may be subject to 
implementation by the federal entity selected to administer the Alert Gateway. Nonetheless, we support 
the CMSAAC s recommended approach of allowing the Alert Gateway to create messages using CAP 
fields and SAME codes. 141 Specifically, we believe that this approach would enable the provision of 
consistent and accurate messages to the public, while facilitating future enhancements to the Alert 
Gateway. 

46. We also agree with the CMSAAC that automatic generation of messages via CAP fields 
and SAME codes may not always provide sufficient flexibility to alert initiators to tailor messages for 
emergencies that may fall with the Imminent Threat Alert category. 142 A message with a translated event 
code of "security warning," for example, may not provide adequate information about a shooting incident 
on a college campus. A more apt warning might be "a shooting has occurred on the north campus," with 
directions to "stay indoors." We thus believe that the public interest would be served if the CMAS 
architecture accommodates free-form text messaging, subject to the 90-character text limit that we adopt 
today and our determination that electing CMS providers will generally not be obligated to accept or 
transmit any alert message that includes an embedded URL or phone number. 143 We also agree with the 
CMSAAC that free-form text should be included as a CAP message parameter. 144 

47. Finally, we concur with the CMSAAC that automatic text generation at the Alert 
Gateway would be impractical for Presidential or AMBER Alerts, 145 both of which are likely to be highly 
fact specific. As the CMSAAC noted, the efficacy of a particular AMBER Alert hinges on specific 
information such as a description of a vehicle, abductor, or missing child. 146 Accordingly, we find that 
law enforcement authorities should have the ability to formulate unique message text for the 
dissemination of AMBER Alerts via the CMAS. We envision that such free text messages would be 
presented to the Alert Gateway in a free text CAP field. In the event of a Presidential Alert, we agree 
with the CMS SAC that, until such time as electing CMS providers are able to transmit messages longer 
than 90 characters, the Alert Gateway may employ a generic statement such as "The President has issued 
an emergency alert. Check local media for more details." 147 

4. Geo-targeting CMAS Alerts 

48. The CMSAAC recommended that "to expedite initial deployments of CMAS an alert that 
is specified by a geocode, circle or polygon" should "be transmitted to an area not larger than the CMS 
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[provider's] approximation of coverage for the county or counties with which that geocode, circle, or 
polygon intersects." 148 Based on the substantial record before us and for the reasons stated below, we 
require electing CMS providers to geographically target (geo-target) alerts accordingly. We note that 
radio frequency (RF) propagation areas for some paging systems and cell sites may exceed a single 
county, and we will permit geo-targeting that exceeds county boundaries in these limited circumstances. 

49. Congress recognized the importance of geo-targeting alerts in the WARN Act. 
Specifically, in section 604 of the WARN Act, Congress directed the Under Secretary of Homeland 
Security for Science and Technology, in consultation with the National Institute of Standards and 
Technology (NIST) and the FCC, to establish a research program for "developing innovative technologies 
that will transmit geographically targeted emergency alerts to the public." 149 The Commission stands 
ready to work with DHS and NIST to facilitate this important undertaking. 150 We fully expect that as 
more refined and cost effective geo-targeting capabilities become available to electing CMS providers, 
they will voluntarily elect to target alerts more granularly. Several CMS providers have indicated their 
intention to geo-target alerts below the county level and we strongly encourage them to do so. 151 As T- 
Mobile notes, electing CMS providers should be free to target more specifically, subject to the liability 
protections of the WARN Act. 152 

50. In the CMAS NPRM, we sought comment on what level of precision the Commission 
should require for geo-targeting, 153 considering the CMSAAC's recommendation for county-level geo- 
targeting. 154 The CMS AAC recognized "that it is the goal of the CMAS for CMS providers to be able to 
deliver geo-targeted alerts to the areas specified by the Alert Initiator." 155 Based upon current capabilities 
and to expedite initial deployments, the CMS AAC recommended targeting "an area not larger than the 
CMS [provider' s] approximation of coverage for the county or counties with which [a transmitted] 
geocode, circle, or polygon intersects." 156 The CMS AAC recommended that providers should be allowed 
(but not required) to deliver alerts to areas smaller than a county, using Geographic Names Identification 
System (GNIS) codes, polygon, or circle information to identify a predefined list of cell sites/paging 
transceivers within the alert area. 157 

51. Several parties however urge us to mandate sub-county targeting. Alert Systems claims 
that disaster managers often require greater geographic granularity than that permitted by CAP and the 
CMSAAC recommendations. 158 Purple Tree Technologies asserts that sub-county targeting is "possible 



148 CMSAAC recommendations, § 5.4. 
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with cell broadcast," and that there are few technical hurdles preventing granular alerts. Acision and 
CellCast both contend that cell broadcast technology would allow for targeting to the individual cell 
level. 160 DataFM claims its technology could target "specific geographic areas without regard to the 
location of its transmitters." 161 

52. The National Emergency Number Association (NENA) favors targeting smaller areas, 
noting that some counties are very large and that alert originators often need to target precisely. 162 NENA 
asserts that targeting messages to the block level (similar to emergency telephone notification systems) 
would be "ideal," but recognizes this is not possible. 163 The CAPUC argues that county targeting would 
be overbroad for most emergencies, and urges ZIP-code level targeting. 164 We note that there are more 
than 40,000 active ZIP codes in the United States, and many of these are assigned to specific addresses. 165 
The CAPUC does not explain how ZIP code targeting could be implemented. 166 

53. The weight of the record supports county-level targeting as recommended by the 
CMSAAC. CTIA, TIA and 3G Americas urge us to implement county-level targeting, with optional 
granularity, to encourage expeditious deployment of alerting capabilities. 167 T-Mobile agrees that 
electing CMS providers should not be not required to target alerts to areas smaller than a county, noting 
that given current technological limitations, many carriers would be unable to achieve more specificity. 168 
Alltel also supports county-level targeting, but states that it intends to target more granularly. 169 

54. MetroPCS notes that for smaller targeting areas, electing CMS providers would have to 
more precisely control the delivery of messages by the base stations serving a given targeted area than is 
currently economically feasible. 170 Similarly, The National Telecommunications Cooperative 
Association (NTCA) states that requiring electing rural CMS providers to send alerts to sub-county areas 
may be too expensive and may reduce the incentive to participate in the CM AS. 171 The American 
Association of Paging Carriers (AAPC) opposes county-level targeting, noting that it may not be feasible 



159 Purple Tree Comments at 2, 11. We reject Purple Tree Technologies' suggestion that polygon information 
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166 We also note that New York City, which did not file comments, previously expressed concern that alerts should 
be targeted more precisely than county-level. See CMASNPRM, 22 FCC Red at 21982, n.40. 

167 cjja Comments at 7, 8; TIA Comments at 3, 4; 3G Americas Comments at 9. 

168 T-Mobile Comments at 17. 

169 Alltel Comments at 4-5. 

170 MetroPCS Comments at 4-5. 

171 NTCA Reply Comments at 4. 



22 



Federal Communications Commission 



FCC 08-99 



for some paging providers to confine alerts to the county level, and that they would target alerts to the 
extent permitted by their networks. 172 

55. Based on the foregoing, and subject to the limited exception discussed below, we 
conclude that it would be premature for us generally to require targeting of alerts more precisely than the 
county level. We specifically note that county-level targeting is consistent with the current practices of 
the National Weather Service, which is expected to originate many CMAS alerts. While some 
commenters argue that cell broadcast and perhaps other technologies could support more granular 
targeting, 173 the record indicates that not all CMS providers may employ cell broadcasting for their 
delivery of CMAS. Further, while several vendors urge us to mandate sub-county targeting, 174 at this 
point we find that the public interest is best served by enabling participating CMS providers to determine 
which technologies will most efficiently and cost effectively allow them to target alerts more precisely 
than the county level. 

56. Accordingly, we generally require CMS providers that elect to participate in the CMAS 
to geographically target emergency alerts to the county level. In adopting this rule, we recognize the 
concerns of many CMS providers that face technical limitations on their ability to geo-target alerts to 
areas smaller than a county. In those limited circumstances where the propagation area of a paging 
system or cell site exceeds a single county, we will permit the RF signal carrying the alert to extend 
beyond a county's boundaries. Electing CMS providers may determine which network facilities, 
elements, and locations will be used to transmit alerts to mobile devices. Regarding the CMSAAC 
recommendation that, until such time as emergency alerts can be delivered to areas smaller than a county 
in real-time (i.e., dynamic geo-targeting), certain urban areas with populations of greater than 1 million or 
with specialized alerting needs be identified for more precise geo-targeting, 175 we will address this 
recommendation once an entity has been identified to provide the Alert Aggregator and Gateway 
functions. 

5. Meeting the Needs of Users, Including Individuals with Disabilities and the 
Elderly 

57. Section 603(b)(3)(F) of the WARN Act required that the CMSAAC include 
representatives of national organizations representing people with special needs, including individuals 
with disabilities and the elderly. 176 Because the WARN Act directed the CMSAAC to submit 
recommendations to the Commission "as otherwise necessary to enable electing CMS providers to 
transmit emergency alerts to subscribers," 177 the CMSAAC concluded, and we agree, that Congress 
intended to include the elderly and those with disabilities among the class to which electing CMS 
providers are to deliver alerts. Accordingly, we conclude that CMAS access to those with disabilities and 
the elderly falls within our obligation under section 602(a) of the WARN Act, and thus seek to ensure that 
commercial mobile alerts are accessible to all Americans, including individuals with disabilities and the 
elderly. 

58. The CMSAAC recommended that the needs of individuals with disabilities and the 
elderly be addressed by, inter alia, the inclusion of a common audio attention signal, and a common 
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vibration cadence, on devices to be used for commercial mobile alerts. 178 The CMSAAC recommended 
that both functions be distinct from any other device alerts and restricted to use for commercial mobile 
alerting purposes. 179 The CMSAAC further noted that these features would benefit not only individuals 
with disabilities and the elderly, but also subscribers more generally. 

59. For devices with polyphonic capabilities, the CMSAAC recommended that the audio 
attention signal should consist of more than one tone, in a frequency range below 2 kHz and preferably 
below 1 kHz, combined with an on-off pattern to make it easier for individuals with hearing loss to 
detect. 180 For devices with only a single frequency capability, the CMSAAC recommended an audio 
attention signal below 2 kHz. 181 The CMSAAC also recommended that the unique vibration cadence 
should be noticeably different from the default cadence of the handset. 182 The CMSAAC further 
recommended that if a device includes both the audio and vibration functions, simultaneous activation of 
both functions should not be required and that configuration should be determined by end users. 183 

60. In the CMAS NPRM, we sought comment on the CMSAAC recommendations, including 
any technical or accessibility requirements that we should adopt to ensure that commercial mobile alerts 
will be received by individuals with disabilities and the elderly. 184 We asked whether attention signals 
should be required for all users. 185 We also noted that the CMSAAC recommended that alert initiators 
use clear and simple language whenever possible, with a minimal use of abbreviations and the ability to 
recall alert messages for review — and sought comment on these recommendations within the context of 
accessibility for individuals with disabilities and the elderly. 186 

61. Nearly all commenting parties support the CMSAAC 's recommendations for addressing 
the needs for individuals with disabilities and the elderly. AT&T, for example, states that adoption of the 
CMSAAC's recommendations for a common audio signal and vibration cadence will "allow for the 
immediate identification of emergency alerts" and foster "the widest possible distribution of alerts" to the 
public. Alert Systems likewise notes that "[ujrgency coding of messages is vital," and that 
caretakers and operators of certain industrial facilities in particular "need unique alert tone 
patterns/amplitudes to quickly reprioritize activities." 189 

62. The Wireless Rehabilitation Engineering Research Center for Wireless Technologies 
(Wireless RERC) supports adoption of a common audio attention signal, and recommends that we adopt 
the existing 8-second EAS attention signal for all users, asserting that it provides the necessary period of 
time to alert individuals with hearing disabilities. 190 The Wireless RERC also supports adoption of a 
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common vibration cadence, and states that electing CMS providers should provide clear instructions on 
the alert capabilities of their devices, including labels identifying mobile devices suitable for persons with 
audio and visual disabilities. 191 AAPC supports the CMSAAC recommendations, but states that legacy 
devices should not be required to support such functions. 192 CAPUC adds that although the CMSAAC 
was required to issue recommendations on wireless alerts exclusively, the Commission should consider 
ensuring interoperability with wireline devices for individuals with disabilities and the elderly, noting that 
some such users may not have access to wireless devices. 193 DataFM notes that it currently has 
equipment for text-to-speech for the blind and strobe light warnings for the deaf, and would employ audio 
alerts and vibration alerts for portable devices. 194 

63. Although there is near unanimous support of the CMSAAC's recommendations for 
addressing the needs of individuals with disabilities and the elderly, several parties argue that no 
additional requirements are necessary. MetroPCS claims that the handsets that will be used to receive 
mobile alerts are already subject to disability access requirements, and any additional requirements may 
raise costs thereby discouraging CMS provider participation. 195 CellCast argues that no changes to CMS 
provider networks should be required, noting that some mobile devices can be configured to enable the 
elderly or blind to hear an audio conversion of the message using text-to-speech technologies. 196 

64. We agree with the majority of those commenting and the CMSAAC that it is vital that we 
ensure access to commercial mobile alerts by individuals with disabilities and the elderly. We disagree 
with the premise articulated by some commenters that merely because some device manufacturers already 
include accessibility features for receipt of mobile alerts, no requirements are needed to ensure access to 
mobile alerts for individuals with disabilities and the elderly. 

65. Accordingly, to address the needs of these user groups and the needs of users more 
generally, we will require that participating CMS providers include both a common vibration cadence and 
a common audio attention signal on any device offered to the public for reception of commercial mobile 
alerts. 197 Specifically, as the CMSAAC recommended, we specify a temporal pattern for the audio 
attention signal of one long tone of two (2) seconds, followed by two short tones of one (1) second each, 
with a half (0.5) second interval between the tones. 198 We will also require that the entire sequence be 
repeated twice with a half (0.5) second interval between repetitions. 199 For devices with polyphonic 
capabilities, we adopt the CMSAAC's recommendation that the audio attention signal consist of the two 
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EAS tones (853 Hz and 960 Hz). For devices with a monophonic capability, we will require that a 
universal audio attention signal be of 960 Hz (the higher frequency EAS tone). 

66. We also seek to facilitate recognition of alerts for individuals that may have a hearing 
disability (or who may have muted the audio attention signal on their device), and therefore adopt the 
same temporal pattern for the vibration cadence as the CMSAAC recommended that the Commission 
specify for the audio attention signal. We strongly encourage CMS providers to coordinate with device 
manufacturers to utilize existing technologies to comply with these requirements as soon as possible. 

67. We recognize that incorporating capabilities for a common audio attention signal and a 
common vibration cadence on the many devices that we expect to be offered to the public will take time 
to develop and implement successfully. However, we believe that assuring full access for all Americans 
is sufficiently important that equipment may not be considered CMAS compliant unless it includes both 
the common audio attention signal and the vibration cadence adopted in this Report and Order. Further, 
both functions must be distinct from any other incoming message alerts and restricted to use for CMAS 
alerting puiposes. Finally, simultaneous activation of both the audio attention signal and vibration 
cadence is permissible. 200 

6. Output Mode/Display 

68. The CMSAAC issued several recommendations regarding the output mode/display of 
mobile devices. 201 Specifically, the CMSAAC recommended that CMAS-enabled mobile devices should 
employ display fonts that are easily readable with recognizable characters, citing three typeface 
examples. 202 MetroPCS notes that certain accessibility requirements already apply to CMS providers, 
and that CMAS-enabled mobile devices will therefore accommodate certain disabilities. 203 CellCast adds 
that the development of mobile devices is highly competitive and flexible enough to meet the needs of all 
users including those with special needs. 204 Although we agree with the CMSAAC that "the goal in font 
selection is to use easily recognizable characters," 205 we do not want to constrain the ability of CMS 
providers and manufacturers of devices to implement display modes that they find will best meet the 
needs of people with disabilities and other users. Accordingly, we do not limit the display of CMAS 
alerts to a particular font or character set. 

69. Text-to-speech (TTS) enabled wireless mobile devices are becoming increasingly 
common, 206 and we strongly encourage all participating CMS providers to offer devices with such 
capabilities so that blind individuals and those with severe visual impairments can obtain the public safety 
benefits of commercial mobile alerts. We note that many of the requirements that we adopt today for the 
first generation of CMAS are intended to enable the provision of text-based alerts to the public. Although 
we envision that the CMAS will evolve to include audio and video service profiles, we find that at this 
initial stage of the CMAS, it would be premature to address the CMSAAC s recommendations regarding 
output mode/displays for such future service profiles. 
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201 See CMSAAC recommendations, § 5.5.2.3. 
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7. Message Retransmission 

70. We agree with the CMSAAC that alerts should be retransmitted periodically to an 
affected area until their specified expiration. 207 Periodic retransmission of alerts is vital because some 
individuals, particularly motorists, may enter an alert area after initial transmission of an alert. Others 
may miss the initial alert because of an ongoing call (as explained below, alerts may not preempt a call in 
progress), 208 or because they had their mobile device turned off or muted when an alert was first 
transmitted. As the CMSAAC noted, the optimal frequency of alert retransmission requires a balancing 
of many factors, including the capabilities of a CMS provider's delivery technology and end users' 
handsets, the number of ongoing active alerts, device battery life, and impacts on network call and data 
processing. The CMSAAC recommended that each CMS provider should determine how often an alert 
will be retransmitted based on such considerations. 209 We agree with this assessment and adopt this 
recommendation as reasonable for the initial implementation of the CMAS. As the system is deployed, 
we may wish to revisit the issue to see if a consistent, industry-wide alert retransmission interval would 
be more appropriate. 

8. Multi-Language CMAS Alerting 

71. The WARN Act required the CMSAAC to submit recommendations to the Commission 
regarding "the technical capability to transmit emergency alerts by electing commercial mobile providers 
to subscribers in languages in addition to English, to the extent practical and feasible." 210 In the CMAS 
NPRM, we sought comment on the technical feasibility of providing commercial mobile alerts in 
languages in addition to English, 211 including how the provision of alerts in multiple languages could 
affect the generation and distribution of messages on a local, state, and national level. 212 Based on the 
record before us, we find that it would be premature to require CMS providers to transmit alerts in 
languages in addition to English. As explained below, we agree with the CMSAAC and those 
commenters that state that further technical study is needed to enable the provision of alerts in multiple 
languages. 

72. The CMSAAC provided recommendations regarding multi-language alerting in section 
5.7 of its report. The CMSAAC specifically "recognized that there is a strong desire for the CMAS to 
support Spanish in addition to English," but found that supporting multiple languages in the first 
generation of CMAS could adversely impact system capacity and increase message latency. 213 It noted 
that while Spanish and English would cover 99 percent of all U.S. households, there are more than 37 
languages in the United States that exceed 1 percent of households on a local level. 214 The CMSAAC 
stated that delivering CMAS alerts in these languages would require mobile devices capable of supporting 
at least 16 different character sets. 215 The CMSAAC also stated that some languages require two bytes 
per character rather than one byte per character for English, thereby further limiting message length. 216 
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The CMSAAC found that the technical feasibility of providing alerts in languages in addition to English 
is a highly complex issue requiring further study. Finally, the CMSAAC noted that the CMAS 
architecture can support language extensions and recommended that this capability be reserved for future 
study. 217 

73. Several parties disagree that the technical feasibility of providing alerts in languages in 
addition to English requires further study, and urge us to mandate the provision of alerts in multiple 
languages now. The CAPUC notes that "roughly 30.1 percent of California's population has limited 
English proficiency," 218 and that the State "uses different languages for different types of communications 
. . . [including] Spanish, Cantonese, Mandarin, Tagalog, Vietnamese, Korean, Farsi, Arabic, and 
Hmong." 219 The CAPUC asserts "that various commercial alert service providers represent that they can 
provide alerts in six different languages," 220 but does not identify these service providers. There is no 
evidence in the record before us however of any CMS provider having the current capability to deliver 
alerts in six different languages, and we therefore cannot adopt CAPUC s request that we require 
transmission of alerts in a minimum of six languages. 221 

74. CellCast and One2many also urge us to implement multiple language alerting. CellCast 
notes that pending standards under the ITU for Message Indicators (Mis) can facilitate either the 
dedication of discrete Mis for specific languages, or the rejection of messages in undesired languages via 
the message preamble. 222 CellCast suggests that such standards would provide clear direction for 
international harmonization of emergency alerting systems and handsets. 223 CellCast further argues that 
the potential latency of multiple messages in sequential languages would be indiscernible to a mobile user 
and should not impact that user's ability to react to an emergency. 224 CellCast claims that the delivery of 
multi-language alerts would not add any new burden on the Alert Aggregator or the CMS provider, and 
would not require any development of new technology. 225 One2many states that there are numerous 
"channels," or Message Identifiers, available in a cell broadcast. 226 According to One2many, end users 
can activate their phones to receive messages on the channel number that matches their language. 227 

75. By contrast, most parties in this proceeding concur with the CMSAAC that further study 
of multiple language alerting is necessary. CTIA, for example, states that we should not require electing 
CMS providers to transmit alerts in multiple languages because of limitations in providers' existing air 
interfaces, handset character sets, and traffic overflow. 228 Regarding the varying air interfaces, Alltel 
concurs with the CMSAAC that transmitting multi-language alerts is not technically feasible for CDMA 



217 Id. 

218 CAPUC Comments at 19. 
219 W.,n.l6. 

220 Id. at 20. 

221 See id. at 19. 

222 

CellCast Comments at 46. 

223 

CellCast Reply Comments at 20. 

224 CellCast Comments at 47-48. 

225 CellCast Reply Comments at 22-23. 

226 One2many Comments at 7. 
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Id. ; see also DataFM Comments at 13. 
228 CTIA Comments at 9-10; CTIA Reply Comments at 7-9. 
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systems, subject to future review as technology improves. According to Alltel, GSM can support 
multiple channels for simultaneous broadcast and discrete channels could be dedicated to different 
languages. 230 Alltel explains that CDMA lacks this capability and would require sequential broadcasts of 
alerts in multiple languages with the potential for unacceptable latency between broadcasts of the same 
language while alerts in multiple languages are sequentially broadcast. 231 

76. With respect to character set limitations in mobile devices, MetroPCS states that most 
handsets currently marketed in the United States use the Latin alphabet and would not support other 
languages — and that adding such capabilities would create substantial burdens on electing CMS providers 
and manufacturers, while increasing the costs of handsets to consumers. 232 The American Association of 
Paging Carriers similarly explains that parallel alerts in languages other than English would threaten 
network congestion, and complicate subscriber device designs and capabilities. 233 T-Mobile adds that a 
multi-language requirement would impede CMAS deployment, and that until the technology improves to 
facilitate multiple languages, non-English speaking users could be prompted by an English alert to turn to 
sources in their respective languages for further information. 234 

77. Several parties, including AT&T, recommend that the Commission initially require alerts 
only in English, but also develop a national plan that provides federal, state, and local alert initiators with 
clear guidance on how alert initiators must craft multi-language alerts that reach the electing CMS 
Provider Gateways in a standardized format ready for end-user delivery without translation. 235 The 
CAPUC, which advocates mandatory multi-language alerting, urges the Commission to examine whether 
latency or delivery concerns could be resolved if language receipt were part of a pre-subscription 
process. 236 The Wireless RERC asks that we encourage providers serving non-English speaking users to 
install software that will automatically translate English emergency messages into other languages, 
especially given the potential delay caused by an alert originator having to send out messages in multiple 
languages. 237 These parties' insightful comments as well as those discussed above underscore that 
electing CMS providers face many technical challenges as they seek to implement alerting in languages in 
addition to English. Accordingly, we conclude that further study is needed to develop capabilities for 
providing alerts in multiple languages, and do not require provision of alerts in any language other than 
English at this time. We encourage the wireless industry and the public safety community to 
expeditiously develop and implement capabilities to deliver alerts in languages in addition to English. 



229 Alltel Comments at 5-6. 

230 T j . c 

Id. at 5. 

231 

Id. ; Alltel Reply Comments at 4; see also TIA Comments at 8-10. 

232 

MetroPCS Comments at 5; cf. Alert Systems Comments at 18-19. Alert Systems argues that regulatory 
mechanisms for alternate languages are unnecessary because the system's development is really only limited by the 
font sets of the receiving devices and by the ability of disaster management agencies to prepare warnings in other 
languages. Id. 

233 AAPC Comments at 8. 

234 T-Mobile Comments at 13-14. 

235 AT&T Comments at 15-16; CTIA Reply Comments at 7-9. 

236 Id. 

237 

Wireless RERC Comments at 12. T-Mobile, however, criticizes this suggestion in its reply comments, noting 
that such an existing technology is not identified in the record, and that it is against the CMSAAC's goal of uniform, 
error-free messaging to allow multiple carriers to create their own versions of alerts in various languages. T-Mobile 
Reply Comments at 7-8. T-Mobile contends that the only means for transmitting multi-language alerts is for the 
Alert Aggregator to send messages in multiple languages, as the CMSAAC recommends. Id. at 8. 
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9. Roaming 

78. We agree with the CMSAAC and the majority of commenting parties that the public 
interest will be served by requiring participating CMS providers to support CMAS alerting when 
subscribers are receiving services through roaming. 238 As discussed further below, we find that adopting 
such a requirement is consistent with our responsibility under the WARN Act to enable commercial 
mobile service alerting, 239 as well as our duty under Executive Order 13407 to "adopt rules to ensure that 
communications systems have the capacity to transmit alerts and warnings to the public as part of the 
public alert and warning system." 



240 



79. In the Automatic Roaming Order, the Commission found that "consumers have come to 
expect seamless wireless service wherever they travel within the United States and, ultimately, this will 
be achieved through automatic roaming." 241 Thus, as a general matter, mobile device users will anticipate 
that the alerting features and services available to them in their home market will be available when 
roaming. Under the rules we adopt today, when a subscriber receives services pursuant to a roaming 
agreement and the operator of the roamed upon network is a participating CMS provider, the subscriber 
will receive alerts messages, provided the subscriber's mobile device is configured for and technically 
capable of receiving alert messages from the roamed upon network. 242 

10. Preemption of Calls in Progress 

80. The CMSAAC recommended that CMAS alerts not preempt ongoing voice or data 
sessions. 243 We agree with this recommendation. We believe that it would be contrary to the public 
interest if alert messages were to preempt certain active voice or data sessions. During a crisis, such as a 
terrorist attack, many individuals will be seeking emergency aid related to the actual event and other 
emergencies. In either circumstance, the public would be ill served if their calls for urgent aid were 
summarily preempted. In light of this, we will require that any device marketed as "CMAS compliant" 
must not permit an alert to preempt an ongoing call. 

D. Service Profiles 

81. In its recommendations, the CMSAAC introduced the concept of technology-neutral 
service profiles for emergency alerts, each containing, for example, information on maximum payload 
and display able message size. 244 The CMSAAC further recommended specific service profiles for: (a) 
Text; (b) Streaming Audio (future capability); (c) Streaming Video (future capability); and (c) 
Downloaded Multimedia Profile (future capability), and provided general recommendations and 



238 CMSAAC recommendations, § 5.9. 

239 WARN Act, § 602(a). 

240 Executive Order 13407, § 3(b)(iii). 



241 Reexamination of Roaming Obligations of Commercial Mobile Radio Service Providers, WT 05-265, Report 
and Order and Further Notice of Proposed Rulemaking, 22 FCC Red 15817, 15855, f76 (2007). We note that the 
scope of the Commission's automatic roaming requirement is applicable to CMRS carriers "if such carriers offer 
real-time two-way switched voice or data service that is interconnected with the public switched network and 
utilizes an in-network switching facility that enables the carrier to re-use frequencies and accomplish seamless hand- 
offs of subscriber calls." See Al C.F.R. § 20.12(a)(2). The automatic roaming requirement is also applicable to the 
provision of push-to-talk and text-messaging service by CMRS carriers. Id. 

242 

We will defer consideration of any subscriber notification requirements related to CMAS roaming to our 
forthcoming order addressing the WARN Act's requirements under section 602(b) for CMAS provider elections to 
support CMAS. 

243 

CMSAAC recommendations, § 7.3. 
244 CMSAAC recommendations, § 6 (Service Profiles). 
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conclusions for each. In the CMAS NPRM, we sought comment on the service profiles recommended by 
the CMSAAC. We agree with those commenters who argue that we should adopt the CMSAAC's 
recommendation that text-only alerts are appropriate for an initial system. 245 Because we believe that it 
would be premature and not consistent with our obligations under section 602(a) of the WARN Act to 
adopt standards and requirements for technologies that are still under development, this order will not 
address future technologies such as streaming audio, video and downloadable multimedia. Rather, this 
order will only address CMSAAC recommended profiles for text. 

82. As part of the text profile, the CMSAAC recommended a maximum displayable message 
size of 90 characters. We sought comment on this recommendation in the CMAS NPRM. 246 Several 
commenters support the CMSAAC's recommendation. For example, AT&T states that, "given the 
current technical limitations in delivering emergency alerts, during the nascent stages of the CMAS the 
Commission should limit alerts to 90 characters . . ," 247 Motorola supports this view and notes that 
inclusion of additional information and characters beyond 90 characters will strain the network, causing 
few people to receive the alert. 248 AAPC states that the 90 character limit strikes an appropriate balance 
between complexity and a reasonably constructed CMAS. 249 Other commenters raised concerns that a 90 
character limit would not provide sufficient information to subscribers about emergencies. For example, 
CellCast states in their comments that 90 characters alone is insufficient to convey a complete alert to 
mobile devices. 250 Furthermore, one commenter stated that the "character count recommendations are 
reasonable for display of 'basic' warnings but CMSAAC recommendations should accommodate 
supplemental and verbose message formats." 251 

83. We conclude that, at this initial stage, adoption of a 90 character limit serves the public 
interest. We agree with commenters such as MetroPCS that a 90 character limit will allow all systems to 
transmit the message with minimal change, and that 90 characters is an effective limit to allow the 
message to be delivered and actually be read. 252 As the CMSAAC concluded and the Wireless 
Rehabilitation Engineering Research Center (WRERC) notes, the 90 character text limit of any CMAS 
alert is reasonable because the CMAS alert is intended to get the attention of a person. The person can 
then seek out other media for confirmation of the alert and more information. 253 

84. The CMSAAC also recommended that where the alert coming into the Alert Gateway 
contains a link to an Internet web site (or URL) as a resource element, the Alert Gateway would retrieve 
any file specified by the URL and deliver that file to the CMS Provider Gateway. This is a different issue 
from the URL in free text issue discussed above, because it implicates the manner in which the alert is 
sent to the CMS Provider Gateway, as opposed to the actual content of the alert itself. We agree with the 
CMSAAC that CMS provider networks do not have the resources to process alerts with internet links. 
Further, URLs may link the CMS Provider Gateway to untrusted Internet sites that could fall outside the 
security requirements that the electing CMS providers have indicated are an essential element of the 



' See, e.g. Purple Tree Technology Comments at 9, AT&T Comments at 10. 
'CMAS NPRM, 22 FCC Red at 21980-81, f 15. 

AT&T Comments at 8 

Motorola Comments at 3. 
' AAPC Comments at 5. 
1 See CellCast Comments at 28. 

See Kendall Post of Alert Systems, Inc. at 15. 

Metro PCS Comments at 3. 
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CMAS. Accordingly, in the CMS provider profile, no alerts with internal URLs may be accepted. 
Rather, related files or other resource elements must be provided separately by the Alert Gateway to the 
CMS Provider Gateway. 

85. We also adopt the CMSAAC observation that the CMAS profiles will not be able to 
accommodate real-time content, including a Presidential alert, even in text format. We believe that the 
CMSAAC has given sufficient indication of the limits of current CMS provider architecture to support 
this conclusion. Currently, the only real-time alert that could potentially be provided to the CMAS is the 
Presidential alert (Emergency Alert Notification or EAN). In the event that such a significant event were 
to occur, all broadcast media would be carrying the message, and as the Wireless RERC recommends, 
instructing the public to tune to their local radio and television station and other mass media is the best 
option for obtaining additional emergency information. 255 

86. The text profiles we adopt today are reflected in table below: 



Text Profile 



Service Profile: Text_Universal_Service_Profile 


Attribute Name 


Attribute Definition 


Note 


Purpose 


Common denominator for text messages 




Maximum Payload 
Size 


1 20 bytes 


Size is estimated 


Maximum Displayable 
Message Size 


90 characters for an English language CMA encoded 
with 7-bit encoding 


Languages other than English, or coding 
other then 7-bit coding, will result in a 
change to the maximum number of 
characters supported 


Data Coding Scheme 


UTF-8 as defined in IETF RFC-3629 


The text provided over the C interface is 
provided in UTF-8 format which is 
capable of supporting text in English and 
other languages. It is the responsibility of 
the CMS Provider Gateway to translate 
to any character format encoding 
required by the CMS provider selected 
delivery technology. 



E. Security for CMAS Alerts 

87. The CMSAAC recommended a specific Alert Aggregator and Alert Gateway Trust 
Model to assure the security, authentication and authorization of alerts from the Alert initiator to the CMS 
Provider Gateway. The CMSAAC also recommended security requirements for communications across 
the "C" interface between the Alert Gateway and CMS Provider Gateways and within each CMS 
provider's network. For example, the CMSAAC recommended that communications across the "C" 
interface be IP based. According to the CMSAAC, the security of the Reference Point C interface should 
be based upon standard IP security mechanisms such as VPN tunnels and IPSEC functionalities. 256 

88. We find that an IP-based communications across the "C" interface serves the public 
interest because it would enhance the security of the CMAS. Accordingly, we adopt the CMSAAC s 
recommendation. We disagree with Purple Tree Technologies' concerns that the protocols put forth are 



The only exception to this is the Presidential alert, which will be transmitted provided it meets the 90-character 
limit. 

255 Wireless RERC Comments at 9. 

256 See CMSAAC recommendations, § 8.3 
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insufficient to provide the security required, and that a higher layer security protocol is necessary over the 
"C" interface between the Alert and CMS Provider Gateways. 257 Rather, we agree with Verizon 
Wireless, which in its Reply Comments rejects such a need. 258 As Verizon Wireless correctly points out, 
under the CMAS Reference Architecture, which we have adopted in this Order, the need for higher layer 
security protocols exists only as an element of the "Trust Model," which addresses the linkage between 
the Alert Gateway and alert initiators. 259 By the time the Alert Gateway hands off a particular alert to the 
CMS Provider Gateway, any necessary authentication and authorization has been completed, thus 
obviating the need for a higher level security layer over the "C" interface. 

89. The CMSAAC recommended that the security at Reference Points D and E be based 
upon CMS provider policies and upon the capabilities of the CMS provider selected delivery 
technologies. No commenter opposes this recommendation, and we believe that the recommendation is 
consistent with the technologically neutral policy of this order and is consistent with section 602(a) of the 
WARN Act which requires that we adopt technical requirements necessary to facilitate emergency alert 
capabilities of CMS providers. Accordingly, we adopt this recommendation of the CMSAAC. 

F. CMAS Reliability and Performance 

90. The CMSAAC made general recommendations concerning CMAS system performance 
requirements. Most requirements are prospective observations and recommendations. Major ones 
include: 

• Alert Gateway capacity. Based on historical data, the CMSAAC made certain predictions 
concerning Alert Gateway performance requirements, including the capability to monitor system 
utilization for capacity planning purposes, and to temporarily disable and buffer CMAS alert 
traffic in the event of an overload. 

• Assessing latency in alert delivery. The CMSAAC stated that such an assessment would be 
difficult to make prior to deployment, but notes certain relevant factors, including; mobile device 
battery life impact, call processing impact; capabilities of the delivery technology; message 
queues; number of languages; number of targeted cell sites/paging transceivers for the alert area; 
and any geo-targeting processing. 

• End to end reliability. The CMSAAC recommends that the CMAS end-to-end reliability 
technology meet telecom standards for highly reliable systems, but notes that the over-all 
reliability of CMAS is unpredictable because RF transmissions can be subject to noise and other 
interference or environmental factors; the capabilities of the cellular environment are not 
predictable especially in a disaster environment; the subscriber may be in a location that does not 
have any RF signal; and the subscriber's mobile device may not have any remaining power. 

91. In order to assure the reliability and performance of this new system, the CMSAAC 
recommended procedures for logging CMAS alerts at the Alert Gateway and for testing the system at the 
Alert Gateway and on an end-to-end basis. Because this presumes the existence of an entity acting in the 
role of Alert Aggregator/Gateway, we cannot adopt rules in this area at this time. 260 
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G. Timeline for Implementation of Technical Requirements, Standards and Protocols. 

92. In its recommendations, the CMSAAC proposed a specific timeline for the 
implementation of the CMAS. According to the CMSAAC, it would take a minimum of 24 months from 
the date by which CMS providers must elect to participate in the CMAS under section 602(b)(2)(A) of the 
WARN Act) to deploy the CMAS. 261 The CMSAAC proposed deployment timeline was based upon the 
assumptions that (1) the CMSAAC recommendations contained within this document are accepted 
without any major technical changes and (2) the government documentation and deliverables are 
available at the milestone dates indicated on the timeline. In this regard, the CMSAAC also assumed that 
the requirements, development, and deployments of the Alert Gateway and Alert Aggregator would align 
with the CMS provider developments to allow for testing during the development process and prior to 
CMAS deployments. The CMSAAC recommended timeline assumed that Federal Government interface 
specifications would be available in January, 2008, 10 months before CMAS development and testing 
was to begin. 

93. At the outset we note that the majority of commenters that addressed the issue supported 
the CMSAAC's proposed deployment timeline. 262 Further, in its comments, FEMA asked the 
Commission not to adopt an effective date for these rules until all legal issues regarding the Federal 
government's role in the CMAS have been identified and resolved. In making this request, FEMA 
provided no indication as to when it believes such issues may be resolved. 263 

94. Issues related to the CMSAAC proposed timeline fall under the election provisions of 
section 602(b) of the WARN Act, and so are not strictly within the purview of this initial technical order 
that complies with section 602(a). However, we agree with the CMSAAC that the Alert Aggregator and 
Alert Gateway must be in place in order for CMS providers to complete development of the CMAS and 
to begin receiving and transmitting emergency alerts. 

95. Accordingly, CMS providers must comply with the technical rules we adopt today no 
later than 10 months from the date of announcement of an entity to provide the Alert Aggregator and 
Alert Gateway functions. 264 This time period is consistent with the 10 months the CMSAAC proposed 
timeline indicates would elapse between the availability of the Aggregator/Gateway interface design 
specification and the beginning of CMAS development and testing. We believe that this will give the 
government and industry stakeholders sufficient time to the federal government's role. It will also give 
electing CMS providers adequate time to come into compliance with the rules adopted herein. 265 



261 CMSAAC recommendations, § 12.2. 

262 See n.20, supra. 

263 FEMA Comments at 2. 

264 We state, infra at f 94, that this Report and Order shall become effective 30 days after publication in the Federal 
Register except that the new information collection requirements contained in these rules will not become effective 
prior to OMB approval. However, the rules themselves specifically state that electing CMS providers must comply 
no later than 10 months from the date of announcement of an entity to serve the Alert Aggregator and Alert Gateway 
functions. This is similar to Commission's adoption of rules requiring all EAS Participants to be able to receive 
CAP formatted EAS alerts no later than 180 days after FEMA publishes the technical standards and requirements for 
such FEMA transmissions. See Review of the Emergency Alert System, 22 FCC Red 13275, 13310 and Appendix 
C; see also 47 C.F.R. § 1 1.56. That Order also became effective 30 days after publication in the Federal Register, 
except that new or modified information collections did not become effective prior to OMB approval. 

265 We note that our adoption of an effective date and compliance deadline have no impact on the WARN Act's 
requirement that CMS providers notify the Commission whether or not they intend to transmit emergency alerts 
within 30 days of the Commission's issuance of rules required under section 602(b). See WARN Act, § 602(b). 
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IV. PROCEDURAL MATTERS 

A. Final Regulatory Flexibility Act Analysis 

96. As required by section 603 of the Regulatory Flexibility Act (RFA), 5 U.S.C. § 604, the 
Commission has prepared a Final Regulatory Flexibility Analysis of the possible impact of the rule 
changes contained in this Report and Order on small entities. The Final Regulatory Flexibility Act 
analysis is set forth in Appendix B, infra. The Commission's Consumer & Government Affairs Bureau, 
Reference Information Center, will send a copy of this Report and Order, including the Final Regulatory 
Flexibility Act Analysis, to the Chief Counsel for Advocacy of the Small Business Administration. 

B. Final Paperwork Reduction Act of 1995 Analysis 

97. This Report and Order may contain new information collection requirements subject to 
the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. If the Commission determines that the 
Report and Order contains collection subject to the PRA, it will be submitted to the Office of 
Management and Budget (OMB) for review under section 3507(d) of the PRA at an appropriate time. At 
that time, OMB, the general public, and other Federal agencies will be invited to comment on the new or 
modified information collection requirements contained in this proceeding. In addition, we note that 
pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 
3506(c)(4), we previously sought specific comment on how the Commission might "further reduce the 
information collection burden for small business concerns with fewer than 25 employees. 

C. Congressional Review Act Analysis 

98. The Commission will send a copy of this Report and Order in a report to be sent to 
Congress and the Government Accountability Office pursuant to the Congressional Review Act, see 5 
U.S.C. 801(a)(1)(A). 

D. Alternative Formats 

99. Alternative formats (computer diskette, large print, audio cassette, and Braille) are 
available to persons with disabilities by sending an e-mail to FCC504@fcc.gov or calling the Consumer 
and Governmental Affairs Bureau at (202) 418-0530, TTY (202) 418-0432. 

V. ORDERING CLAUSES 

100. IT IS ORDERED, that pursuant to sections 1, 4(i) and (o), 201, 303(r), 403, and 706 of 
the Communications Act of 1934, as amended, 47 U.S.C. §§ 151, 154(i) and (o), 201, 303(r), 403, and 
606, as well as by sections 602(a),(b),(c), (f), 603, 604 and 606 of the WARN Act, this Report and Order 
IS hereby ADOPTED. The rules adopted in this Report and Order shall become effective 30 days after 
publication in the Federal Register except that the new information collection requirements contained in 
these rules will not become effective prior to OMB approval. 266 



See supra f 95. 
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101. IT IS FURTHER ORDERED that the Commission's Consumer and Government Affairs 
Bureau, Reference Information Center, SHALL SEND a copy of this Report and Order, including the 
Final Regulatory Flexibility Analysis, to the Chief Council for Advocacy of the Small Business 
Administration. 



FEDERAL COMMUNICATIONS COMMISSION 



Marlene H. Dortch 
Secretary 
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APPENDIX A 
List of Commenters 
Comments in PS Docket No. 07-287 



Commenters 


Abbreviation 


3G Americas 


3G Americas 


Acision B.V. and One2Many B.V. 


Acision 


Alliance for Telecommunications Industry Solutions 


ATIS 


Alltel Communications, LLC 


Alltel 


American Association of Paging Carriers 


AAPC 


America's Emergency Network 


AEN 


Association of Public Television Stations 


APTS 


AT&T Inc. 


AT&T 


Audemat- Aztec Inc. 


Audemat-Aztec 


California Public Utilities Commission 


CAPUC 


CellCast Technologies, LLC 


CellCast 


Cellular Emergency Alert Service Association - US Chapter 


CEASA-US 


CTIA - The Wireless Association 


CTIA 


DataFM, Inc. 


DataFM 


Digital Alert Systems, LLC 


DAS 


Ericsson Inc. 


Ericsson 


Florida Association of Broadcasters 


FAB 


Global Security Systems, LLC 


Global 


Interstate Wireless Inc. 


Interstate Wireless 


Jacob Westfall 


Westfall 


Kendall Post 


Post 


Max Mayfield 


Mayfield 


MetroPCS Communications, Inc. 


MetroPCS 


Mississippi Association of Broadcasters 


Mississippi Broadcasters 


Mississippi Emergency Management Agency 


MS -EM A 


Mississippi Office of Homeland Security 


MS-OHS 


Motorola, Inc. 


Motorola 


National Association of Broadcasters 


NAB 


National Emergency Numbering Association 


NENA 


Nokia Inc. and Nokia Siemens Networks US LLC 


Nokia 


Pontotoc County Emergency Management Agency 


Pontotoc EMA 


Purple Tree Technologies 


PTT 


Rehabilitation Engineering Research Center 




for Wireless Technologies 


Wireless RERC 


Rural Cellular Association 


RCA 


Sheriff, Jefferson Davis Parish, Louisiana 


Sheriff 


SouthernLINC Wireless 


SouthernLINC 


Sprint Nextel Corporation 


Sprint Nextel 


SquareLoop, Inc. 


SquareLoop 


Telecommunications Industry Association 


TIA 


T-Mobile USA, Inc. 


T-Mobile 


Verizon Wireless 


Verizon 
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Reply Commenters Abbreviation 

Airadigm Communications - Einstein Wireless Airadigm 

Alltel Communications, LLC Alltel 

American Association of Paging Carriers AAPC 

Association of Public Television Stations APTS 

AT&T Inc. AT&T 

CellCast Technologies, LLC CellCast 

CTIA - The Wireless Association CTIA 

Cox Radio, Inc. Cox 

DataFM, Inc. DataFM 

FEMA, Director, Office of Nat'l Security Coordination FEMA 

Global Security Systems, LLC Global 

Interstate Wireless Inc. Interstate Wireless 

King County, Washington King County 

Motorola, Inc. Motorola 

National Telecommunications Cooperative Association NTCA 

NTI Group, Inc. NTI 

OnStar Corporation OnStar 

Rural Cellular Association RCA 

SquareLoop, Inc. SquareLoop 

T-Mobile USA, Inc. T-Mobile 

Verizon Wireless Verizon 

Ex Parte Commenters Abbreviation 

American Association of Paging Carriers AAPC 

AT&T Inc. AT&T 

CTIA - The Wireless Association CTIA 

DataFM, Inc. DataFM 

Global Security Systems, LLC Global 

National Telecommunications Cooperative Association NTCA 

OnStar Corporation OnStar 

Rural Cellular Association RCA 
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APPENDIX B 
Final Regulatory Flexibility Analysis 

1. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), 1 an Initial 
Regulatory Flexibility Analysis (IRFA) was incorporated in the Notice of Proposed Rulemaking in 
PSHSB Docket 07-287 (CM AS NPRM). The Commission sought written public comments on the 
proposals in the CMAS NPRM, including comment on the IRFA. Comments on the IRFA were to have 
been explicitly identified as being in response to the IRFA and were required to be filed by the same 
deadlines as that established in section IV of the CMAS NPRM for other comments to the CMAS NPRM. 
The Commission sent a copy of the CMAS NPRM, including the IRFA, to the Chief Counsel for 
Advocacy of the Small Business Administration (SB A). 2 In addition, the CMAS NPRM and IRFA were 
published in the Federal Register. 3 

A. Need for, and Objectives of, the Order 

2. Section 602(a) of the WARN Act requires the Commission to "complete a proceeding to 
adopt relevant technical standards, protocols, procedures, and other technical requirements based on the 
recommendations of [the Commercial Mobile Service Alert Advisory Committee (CMSAAC)] necessary 
to enable commercial mobile service alerting capability for commercial mobile service providers that 
voluntarily elect to transmit emergency alerts." 4 Although the CMAS NPRM solicited comment on issues 
related to section 602(b) (CMS provider election to the CMAS) or 602(c) (Public Television Station 
equipment requirements), this CMAS First Report and Order only addresses issues raised by section 
602(a) of the WARN Act. 5 Accordingly, this FRFA only addressees the manner in which any 
commenters to the IRFA addressed the Commission's adoption of technical standards, requirements and 
protocols for the CMAS as required by section 602(a) of the WARN Act. 

3. This CMAS First Report and Order adopts rules necessary to enable CMS alerting 
capability for CMS providers who elect to transmit emergency alerts to their subscribers. The Order 
adopts technologically neutral rules governing the CMS provider-related functions and responsibilities 
with respect to the CMAS. Specifically, the rules address the CMS providers' functions within the 
CMAS, including CMS provider-controlled elements within the CMAS architecture, emergency alert 
formatting, classes and elements, geographic targeting (geo-targeting) and accessibility for people with 
disabilities and the elderly. 

B. Summary of Significant Issues Raised by Public Comments in Response to the IRFA 

4. There were no comments filed that specifically addressed the IRFA. The only 
commenter that explicitly identified itself as a small business was Interstate Wireless, Inc., which 



1 See 5 U.S.C. § 603. The RFA, see 5 U.S.C. §§ 601-612, has been amended by the Small Business Regulatory 
Enforcement Fairness Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857 (1996). 

2 See 5 U.S.C. § 603(a). 

3 73 FR 546-01 (January 3, 2008). 

4 WARN Act § 602(a). 

5 As the CMAS First Report and Order indicates in note 16, supra, the Commission will address these other 
provisions of the WARN Act and related issues in subsequent Orders within the deadlines established by the statute. 



39 



Federal Communications Commission 



FCC 08-99 



supported the Commission's adoption of the CMSAAC's recommendations. 6 Although Interstate 
Wireless did not comment specifically on the IRFA, it did state that the cost of building and maintaining a 
CMS Provider Gateway would be more than it and other similarly situated Small Business CMS 
providers could afford and still be able to provide the alert service to the public without cost. 
Accordingly, Interstate Wireless requested that the Federal Government either provide the proper 
software and reception equipment for the CMS Provider Gateways, or provide grants to the Small 
Business CMS providers to purchase, install, and maintain the equipment themselves. In paragraph 19, 
note 58 of the CM AS First Report and Order the Commission notes that questions of funding are not 
addressed by section 602(a) of the WARN Act and are this outside of the scope of this order. 7 

C. Description and Estimate of the Number of Small Entities to Which Rules Will 
Apply 

5. The RFA directs agencies to provide a description of, and, where feasible, an estimate of, 
the number of small entities that may be affected by the rules adopted herein. 8 The RFA generally 
defines the term "small entity" as having the same meaning as the terms "small business," "small 
organization," and "small governmental jurisdiction." 9 In addition, the term "small business" has the 
same meaning as the term "small business concern" under the Small Business Act. 10 A "small business 
concern" is one which: (1) is independently owned and operated; (2) is not dominant in its field of 
operation; and (3) satisfies any additional criteria established by the Small Business Administration 

(SB A). 11 

6. Wireless Telecommunications Carriers (except Satellite). Since 2007, the SBA has 
recognized wireless firms within this new, broad, economic census category. 12 Prior to that time, the 
SBA had developed a small business size standard for wireless firms within the now-superseded census 
categories of "Paging" and "Cellular and Other Wireless Telecommunications." 13 Under the present and 
prior categories, the SBA has deemed a wireless business to be small if it has 1,500 or fewer employees. 
Because Census Bureau data are not yet available for the new category, we will estimate small business 
prevalence using the prior categories and associated data. For the first category of Paging, data for 2002 
show that there were 807 firms that operated for the entire year. 14 Of this total, 804 firms had 
employment of 999 or fewer employees, and three firms had employment of 1,000 employees or more. 15 

6 Interstate Wireless Comments at 1 . 
See CMAS First Report and Order, n.58, infra 

8 5 U.S. C. § 603(b). 

9 5 U.S.C. §601(6). 

10 5 U.S.C. § 601(3) (incorporating by reference the definition of "small-business concern" in the Small Business 
Act, 15 U.S.C. § 632). Pursuant to 5 U.S.C. § 601(3), the statutory definition of a small business applies "unless an 
agency, after consultation with the Office of Advocacy of the Small Business Administration and after opportunity 
for public comment, establishes one or more definitions of such term which are appropriate to the activities of the 
agency and publishes such definition(s) in the Federal Register." 5 U.S.C. § 601(3). 

11 15 U.S.C. §632. 

12 13 C.F.R. § 121.201, NAICS code 517210. 

13 13 C.F.R. § 121.201, NAICS codes 51721 1, 517212. 

14 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, "Establishment and Firm Size 
(Including Legal Form of Organization," Table 5, NAICS code 5 1721 1 (issued Nov. 2005). 

15 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 
or fewer employees; the largest category provided is for firms with "1000 employees or more." 
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For the second category of Cellular and Other Wireless Telecommunications, data for 2002 show that 
there were 1,397 firms that operated for the entire year. 16 Of this total, 1,378 firms had employment of 
999 or fewer employees, and 19 firms had employment of 1,000 employees or more. 17 Thus, using the 
prior categories and the available data, we estimate that the majority of wireless firms can be considered 
small. 

7. Cellular Service . As noted, the SBA has developed a small business size standard for 
small businesses in the category "Wireless Telecommunications Carriers (except satellite)." 18 Under that 
SBA category, a business is small if it has 1,500 or fewer employees. 19 Since 2007, the SBA has 
recognized wireless firms within this new, broad, economic census category. 20 Prior to that time, the 
SBA had developed a small business size standard for wireless firms within the now-superseded census 
categories of "Paging" and "Cellular and Other Wireless Telecommunications." 21 Accordingly, the 
pertinent data for this category is contained within the prior Wireless Telecommunications Carriers 
(except Satellite) category. 

8. Auctions. Initially, we note that, as a general matter, the number of winning bidders that 
qualify as small businesses at the close of an auction does not necessarily represent the number of small 
businesses currently in service. Also, the Commission does not generally track subsequent business size 
unless, in the context of assignments or transfers, unjust enrichment issues are implicated. 

9. Broadband Personal Communications Service. The broadband Personal 
Communications Service (PCS) spectrum is divided into six frequency blocks designated A through F, 
and the Commission has held auctions for each block. The Commission has created a small business size 
standard for Blocks C and F as an entity that has average gross revenues of less than $40 million in the 
three previous calendar years. 22 For Block F, an additional small business size standard for "very small 
business" was added and is defined as an entity that, together with its affiliates, has average gross 
revenues of not more than $15 million for the preceding three calendar years. 23 These small business size 
standards, in the context of broadband PCS auctions, have been approved by the SBA. 24 No small 
businesses within the SBA-approved small business size standards bid successfully for licenses in Blocks 
A and B. There were 90 winning bidders that qualified as small entities in the C Block auctions. A total 
of 93 "small" and "very small" business bidders won approximately 40 percent of the 1,479 licenses for 
Blocks D, E, and F. 25 On March 23, 1999, the Commission reauctioned 155 C, D, E, and F Block 



U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, "Establishment and Firm Size 
(Including Legal Form of Organization," Table 5, NAICS code 517212 (issued Nov. 2005). 

17 

Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 
or fewer employees; the largest category provided is for firms with "1000 employees or more." 

18 13 C.F.R. § 121.201, North American Industry Classification System (NAICS) code 517210. 

19 Id. 

20 13 C.F.R. § 121.201, NAICS code 517210. 

21 13 C.F.R. § 121.201, NAICS codes 51721 1, 517212. 

22 

See Amendment of Parts 20 and 24 of the Commission's Rules - Broadband PCS Competitive Bidding and the 
Commercial Mobile Radio Service Spectrum Cap, Report and Order, 1 1 FCC Red 7824, 7850-7852 ff 57-60 
(1996); see also 47 C.F.R. § 24.720(b). 

23 

See Amendment of Parts 20 and 24 of the Commission's Rules - Broadband PCS Competitive Bidding and the 
Commercial Mobile Radio Service Spectrum Cap, Report and Order, 1 1 FCC Red 7824, 7852 f 60. 

24 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications 
Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, 
dated December 2, 1998. 

25 FCC News, "Broadband PCS, D, E and F Block Auction Closes," No. 71744 (rel. January 14, 1997). 
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licenses; there were 113 small business winning bidders. 26 On January 26, 2001, the Commission 
completed the auction of 422 C and F PCS licenses in Auction 35. 27 Of the 35 winning bidders in this 
auction, 29 qualified as "small" or "very small" businesses. Subsequent events concerning Auction 35, 
including judicial and agency determinations, resulted in a total of 163 C and F Block licenses being 
available for grant. 

10. Narrowband Personal Communications Service. The Commission held an auction for 
Narrowband Personal Communications Service (PCS) licenses that commenced on July 25, 1994, and 
closed on July 29, 1994. A second commenced on October 26, 1994 and closed on November 8, 1994. 
For purposes of the first two Narrowband PCS auctions, "small businesses" were entities with average 
gross revenues for the prior three calendar years of $40 million or less. 28 Through these auctions, the 
Commission awarded a total of forty-one licenses, 11 of which were obtained by four small businesses. 29 
To ensure meaningful participation by small business entities in future auctions, the Commission adopted 
a two-tiered small business size standard in the Narrowband PCS Second Report and Order?® A "small 
business" is an entity that, together with affiliates and controlling interests, has average gross revenues for 
the three preceding years of not more than $40 million. 31 A "very small business" is an entity that, 
together with affiliates and controlling interests, has average gross revenues for the three preceding years 
of not more than $15 million. 32 The SBA has approved these small business size standards. 33 A third 
auction commenced on October 3, 2001 and closed on October 16, 2001. Here, five bidders won 317 
(MTA and nationwide) licenses. 34 Three of these claimed status as a small or very small entity and won 
311 licenses. 

1 1 . Wireless Communications Services . This service can be used for fixed, mobile, 
radiolocation, and digital audio broadcasting satellite uses in the 2305-2320 MHz and 2345-2360 MHz 
bands. The Commission defined "small business" for the wireless communications services (WCS) 
auction as an entity with average gross revenues of $40 million for each of the three preceding years, and 
a "very small business" as an entity with average gross revenues of $15 million for each of the three 
preceding years. 35 The SBA has approved these definitions. 36 The Commission auctioned geographic 



26 See "C, D, E, and F Block Broadband PCS Auction Closes," Public Notice, 14 FCC Red 6688 (WTB 1999). 

27 See "C and F Block Broadband PCS Auction Closes; Winning Bidders Announced," Public Notice, 16 FCC Red 
2339 (2001). 

28 

Implementation of section 309(j) of the Communications Act - Competitive Bidding Narrowband PCS, Third 
Memorandum Opinion and Order and Further Notice of Proposed Rulemaking, 10 FCC Red 175, 196 f 46 (1994). 

29 

See 'Announcing the High Bidders in the Auction of ten Nationwide Narrowband PCS Licenses, Winning Bids 
Total $617,006,674," Public Notice, PNWL 94-004 (rel. Aug. 2, 1994); "Announcing the High Bidders in the 
Auction of 30 Regional Narrowband PCS Licenses; Winning Bids Total $490,901,787," Public Notice, PNWL 94- 
27 (rel. Nov. 9, 1994). 

30 

Amendment of the Commission's Rules to Establish New Personal Communications Services, Narrowband PCS, 
Second Report and Order and Second Further Notice of Proposed Rule Making, 15 FCC Red 10456, 10476 f 40 
(2000). 

31 Id. 

32 Id. 

33 

See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications 
Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, 
dated December 2, 1998. 

34 See "Narrowband PCS Auction Closes," Public Notice, 16 FCC Red 18663 (WTB 2001). 

35 

Amendment of the Commission's Rules to Establish Part 27, the Wireless Communications Service (WCS), 
Report and Order, 12 FCC Red 10785, 10879 f 194 (1997). 
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area licenses in the WCS service. In the auction, which commenced on April 15, 1997 and closed on 
April 25, 1997, there were seven bidders that won 31 licenses that qualified as very small business 
entities, and one bidder that won one license that qualified as a small business entity. 

12. 700 MHz Guard Bands Licenses. In the 700 MHz Guard Bands Order, the Commission 
adopted size standards for "small businesses" and "very small businesses" for purposes of determining 
their eligibility for special provisions such as bidding credits and installment payments. 37 A small 
business in this service is an entity that, together with its affiliates and controlling principals, has average 
gross revenues not exceeding $40 million for the preceding three years. 38 Additionally, a "very small 
business" is an entity that, together with its affiliates and controlling principals, has average gross 
revenues that are not more than $15 million for the preceding three years. 39 SBA approval of these 
definitions is not required. 40 An auction of 52 Major Economic Area (MEA) licenses for each of two 
spectrum blocks commenced on September 6, 2000, and closed on September 21, 2000. 41 Of the 104 
licenses auctioned, 96 licenses were sold to nine bidders. Five of these bidders were small businesses that 
won a total of 26 licenses. A second auction of remaining 700 MHz Guard Bands licenses commenced 
on February 13, 2001, and closed on February 21, 2001. All eight of the licenses auctioned were sold to 
three bidders. One of these bidders was a small business that won a total of two licenses. 42 
Subsequently, in the 700 MHz Second Report and Order, the Commission reorganized the licenses 
pursuant to an agreement among most of the licensees, resulting in a spectral relocation of the first set of 
paired spectrum block licenses, and an elimination of the second set of paired spectrum block licenses 
(many of which were already vacant, reclaimed by the Commission from Nextel). 43 A single licensee 
that did not participate in the agreement was grandfathered in the initial spectral location for its two 
licenses in the second set of paired spectrum blocks. 44 Accordingly, at this time there are 54 licenses in 
the 700 MHz Guard Bands. 

13. 700 MHz Band Commercial Licenses. There is 80 megahertz of non-Guard Band 
spectrum in the 700 MHz Band that is designated for commercial use: 698-757, 758-763, 776-787, and 
788-793 MHz Bands. With one exception, the Commission adopted criteria for defining two groups of 
small businesses for purposes of determining their eligibility for bidding credits at auction. These two 



(...continued from previous page) 

36 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications 
Bureau, Federal Communications Commission, from Aida Alvarez, Administrator, Small Business Administration, 
dated December 2, 1998. 

37 

See Service Rules for the 746-764 MHz Bands, and Revisions to Part 27 of the Commission's Rules, Second 
Report and Order, 15 FCC Red 5299 (2000). 

38 Id. at 5343f 108. 

39 Id. 

40 Id. At 5343 f 108 n.246 (for the 746-764 MHz and 776-704 MHz bands, the Commission is exempt from 15 
U.S.C. § 632, which requires Federal agencies to obtain Small Business Administration approval before adopting 
small business size standards). 

41 See "700 MHz Guard Bands Auction Closes: Winning Bidders Announced," Public Notice, 15 FCC Red 18026 
(2000). 

42 See "700 MHz Guard Bands Auctions Closes: Winning Bidders Announced," Public Notice, 16 FCC Red 4590 
(WTB 2001). 

43 See In the Matter of Service Rules for the 698-746, 747-762 and 777-792 MHz Bands, WT Docket 06-150, 
Second Report and Order, 22 FCC Red 15289, 15339-15344 ff 1 18-134 (2007) (700 MHz Second Report and 
Order). 

44 Id. 
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categories are: (1) "small business," which is defined as an entity that has attributed average annual gross 
revenues that do not exceed $15 million during the preceding three years; and (2) "very small business," 
which is defined as an entity with attributed average annual gross revenues that do not exceed $40 million 
for the preceding three years. 45 In Block C of the Lower 700 MHz Band (710-716 MHz and 740-746 
MHz), which was licensed on the basis of 734 Cellular Market Areas, the Commission adopted a third 
criterion for determining eligibility for bidding credits: an "entrepreneur," which is defined as an entity 
that, together with its affiliates and controlling principals, has average gross revenues that are not more 
than $3 million for the preceding three years. 46 The SBA has approved these small size standards. 47 

14. An auction of 740 licenses for Blocks C (710-716 MHz and 740-746 MHz) and D (716- 
722 MHz) of the Lower 700 MHz Band commenced on August 27, 2002, and closed on September 18, 
2002. Of the 740 licenses available for auction, 484 licenses were sold to 102 winning bidders. Seventy- 
two of the winning bidders claimed small business, very small business, or entrepreneur status and won a 
total of 329 licenses. 48 A second auction commenced on May 28, 2003, and closed on June 13, 2003, and 
included 256 licenses: five EAG licenses and 251 CMA licenses. 49 Seventeen winning bidders claimed 
small or very small business status and won 60 licenses, and nine winning bidders claimed entrepreneur 
status and won 154 licenses. 50 

15. The remaining 62 megahertz of commercial spectrum is currently scheduled for auction 
on January 24, 2008. As explained above, bidding credits for all of these licenses will be available to 
"small businesses" and "very small businesses." 

16. Advanced Wireless Services. In the AWS-1 Report and Order, the Commission adopted 
rules that affect applicants who wish to provide service in the 1710-1755 MHz and 2110-2155 MHz 
bands. 51 The Commission did not know precisely the type of service that a licensee in these bands might 
seek to provide. Nonetheless, the Commission anticipated that the services that will be deployed in these 
bands may have capital requirements comparable to those in the broadband Personal Communications 
Service (PCS), and that the licensees in these bands will be presented with issues and costs similar to 
those presented to broadband PCS licensees. Further, at the time the broadband PCS service was 
established, it was similarly anticipated that it would facilitate the introduction of a new generation of 
service. Therefore, the AWS-1 Report and Order adopts the same small business size definition that the 
Commission adopted for the broadband PCS service and that the SBA approved. 52 In particular, the 
AWS-1 Report and Order defines a "small business" as an entity with average annual gross revenues for 



See Auction of 700 MHz Band Licenses Scheduled for January 24, 2008, AU Docket No. 07-157, Notice and 
Filing Requirements, Minimum Opening Bids, Reserve Prices, Upfront Payments, and Other Procedures for 
Auctions 73 and 76, DA 07-4171 atf 70 (WTB rel. Oct. 5, 2007); Reallocation and Service Rules for the 698-746 
MHz Spectrum Band (Television Channels 52-59), Report and Order, 17 FCC Red 1022, 1087-88 (2002). 

46 Id. at 1088. 

47 See Letter to Thomas Sugrue, Chief, Wireless Telecommunications Bureau, Federal Communications 
Commission, from Aida Alvarez, Administrator, Small Business Administration, dated August 10, 1999. 

48 See "Lower 700 MHz Band Auction Closes," Public Notice, 17 FCC Red 17272 (WTB 2002). 

49 See 'Lower 700 MHz Band Auction Closes," Public Notice, 18 FCC Red 11873 (WTB 2003). 



Service Rules for Advanced Wireless Services in the 1.7 GHz and 2.1 GHz Bands, WT Docket No. 02-353, 
Report and Order, 18 FCC Red 25162 (2003) (AWS-1 Report and Order). 

52 

See Implementation of section 309(j) of the Communications Act — Competitive Bidding, Third Memorandum 
Opinion and Order and Further Notice of Proposed Rulemaking, 10 FCC Red 175, 196 (1995); Implementation of 
section 309(j) of the Communications Act — Competitive Bidding, Fifth Report and Order, 9 FCC Red 5581-5584 
(1995); 47 C.F.R. §§ 24.320(b) and 24.720(b). 



44 



Federal Communications Commission 



FCC 08-99 



the preceding three years not exceeding $40 million, and a "very small business" as an entity with average 
annual gross revenues for the preceding three years not exceeding $15 million. The AWS-1 Report and 
Order also provides small businesses with a bidding credit of 15 percent and very small businesses with a 
bidding credit of 25 percent. 

17. Common Carrier Paging . As noted, the SBA has developed a small business size 
standard for wireless firms within the broad economic census category of "Wireless Telecommunications 
Carriers (except Satellite)." 53 Under this category, the SBA deems a business to be small if it has 1,500 
or fewer employees. Since 2007, the SBA has recognized wireless firms within this new, broad, 
economic census category. 54 Prior to that time, the SBA had developed a small business size standard for 
wireless firms within the now-superseded census categories of "Paging" and "Cellular and Other Wireless 
Telecommunications." 55 Under the present and prior categories, the SBA has deemed a wireless business 
to be small if it has 1,500 or fewer employees. Because Census Bureau data are not yet available for the 
new category, we will estimate small business prevalence using the prior categories and associated data. 
For the first category of Paging, data for 2002 show that there were 807 firms that operated for the entire 
year. 56 Of this total, 804 firms had employment of 999 or fewer employees, and three firms had 
employment of 1,000 employees or more. 57 For the second category of Cellular and Other Wireless 
Telecommunications, data for 2002 show that there were 1,397 firms that operated for the entire year. 58 
Of this total, 1,378 firms had employment of 999 or fewer employees, and 19 firms had employment of 
1,000 employees or more. 59 Thus, using the prior categories and the available data, we estimate that the 
majority of wireless firms can be considered small. Thus, under this category, the majority of firms can be 
considered small. 

18. In the Paging Third Report and Order, we developed a small business size standard for 
"small businesses" and "very small businesses" for purposes of determining their eligibility for special 
provisions such as bidding credits and installment payments. 60 A "small business" is an entity that, 
together with its affiliates and controlling principals, has average gross revenues not exceeding $15 
million for the preceding three years. Additionally, a "very small business" is an entity that, together with 
its affiliates and controlling principals, has average gross revenues that are not more than $3 million for 
the preceding three years. 61 The SBA has approved these small business size standards. 62 An auction of 



13C.F.R. § 121.201, NAICS code 517211. 

54 13 C.F.R. § 121.201, NAICS code 517210. 

55 13 C.F.R. § 121.201, NAICS codes 51721 1, 517210. 

56 U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, "Establishment and Firm Size 
(Including Legal Form of Organization," Table 5, NAICS code 517211 (issued Nov. 2005). 

57 

Id. The census data do not provide a more precise estimate of the number of firms that have employment of 1,500 
or fewer employees; the largest category provided is for firms with "1000 employees or more." 

58 

U.S. Census Bureau, 2002 Economic Census, Subject Series: Information, "Establishment and Firm Size 
(Including Legal Form of Organization," Table 5, NAICS code 517212 (issued Nov. 2005). 

59 Id. The census data do not provide a more precise estimate of the number of firms that have employment of 
1,500 or fewer employees; the largest category provided is for firms with "1000 employees or more." 

60 Amendment of Part 90 of the Commission's Rules to Provide for the Use of the 220-222 MHz Band by the 
Private Land Mobile Radio Service, PR Docket No. 89-552, Third Report and Order and Fifth Notice of Proposed 
Rulemaking, 12 FCC Red 10943, 1 1068-70, ffs. 291-295, 62 FR 16004 (Apr. 3, 1997). 

61 See Letter to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications 
Bureau, FCC, from A. Alvarez, Administrator, SBA (Dec. 2, 1998). 
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Metropolitan Economic Area licenses commenced on February 24, 2000, and closed on March 2, 2000. 63 
Of the 985 licenses auctioned, 440 were sold. Fifty-seven companies claiming small business status won. 
Also, according to Commission data, 365 carriers reported that they were engaged in the provision of 
paging and messaging services. 64 Of those, we estimate that 360 are small, under the SBA-approved 
small business size standard. 65 

19. Wireless Communications Service . This service can be used for fixed, mobile, 
radiolocation, and digital audio broadcasting satellite uses. The Commission established small business 
size standards for the wireless communications services (WCS) auction. 66 A "small business" is an entity 
with average gross revenues of $40 million for each of the three preceding years, and a "very small 
business" is an entity with average gross revenues of $15 million for each of the three preceding years. 
The SB A has approved these small business size standards. 67 The Commission auctioned geographic 
area licenses in the WCS service. In the auction, there were seven winning bidders that qualified as "very 
small business" entities, and one that qualified as a "small business" entity. 

20. Wireless Communications Equipment Manufacturers . While these entities are merely 
indirectly affected by our action, we are describing them to achieve a fuller record. The Census Bureau 
defines this category as follows: "This industry comprises establishments primarily engaged in 
manufacturing radio and television broadcast and wireless communications equipment. Examples of 
products made by these establishments are: transmitting and receiving antennas, cable television 
equipment, GPS equipment, pagers, cellular phones, mobile communications equipment, and radio and 
television studio and broadcasting equipment." The SBA has developed a small business size standard 
for Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing, which 
is: all such firms having 750 or fewer employees. 68 According to Census Bureau data for 2002, there 
were a total of 1,041 establishments in this category that operated for the entire year. Of this total, 1,010 
had employment of under 500, and an additional 13 had employment of 500 to 999. Thus, under this size 
standard, the majority of firms can be considered small. 69 

21. Radio and Television Broadcasting and Wireless Communications Equipment 
Manufacturing . The Census Bureau defines this category as follows: "This industry comprises 
establishments primarily engaged in manufacturing radio and television broadcast and wireless 
communications equipment. Examples of products made by these establishments are: transmitting and 
receiving antennas, cable television equipment, GPS equipment, pagers, cellular phones, mobile 
communications equipment, and radio and television studio and broadcasting equipment." 70 The SBA 



(...continued from previous page) 

62 Revision of Part 22 and Part 90 of the Commission's Rules to Facilitate Future Development of Paging Systems, 
Memorandum Opinion and Order on Reconsideration and Third Report and Order, 14 FCC Red 10030, ffs. 98-107 
(1999). 

63 Id. at 10085, f . 98. 

64 FCC Wireline Competition Bureau, Industry Analysis and Technology Division, "Trends in Telephone Service" 
at Table 5.3., page 5-5 (Feb. 2007). This source uses data that are current as of October 20, 2005. 

65 Id. 

66 Public Notice, "Auction of Wireless Communications Services, Auction Notes and Filing Requirements for 128 
WCS Licenses Scheduled for April 15, 1997," DA 97-386, Feb. 21, 1997. 

67 SBA Dec. 2, 1998 Letter. 

68 NAICS code 334220. 

69 NAICS code 11210. 

70 

U.S. Census Bureau, 2002 NAICS Definitions, "334220 Radio and Television Broadcasting and Wireless 
Communications Equipment Manufacturing"; http://www.census.gOv/epcd/naics02/def/NDEF334.HTM#N3342. 
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has developed a small business size standard for Radio and Television Broadcasting and Wireless 
Communications Equipment Manufacturing, which is: all such firms having 750 or fewer employees. 
According to Census Bureau data for 2002, there were a total of 1,041 establishments in this category that 
operated for the entire year. 72 Of this total, 1,010 had employment of under 500, and an additional 13 had 
employment of 500 to 999. 73 Thus, under this size standard, the majority of firms can be considered 
small. 

22. Software Publishers . While these entities are merely indirectly affected by our action, we 
are describing them to achieve a fuller record. These companies may design, develop or publish software 
and may provide other support services to software purchasers, such as providing documentation or 
assisting in installation. The companies may also design software to meet the needs of specific users. 
The SBA has developed a small business size standard of $23 million or less in average annual receipts 
for the category of Software Publishers. For Software Publishers, Census Bureau data for 2002 indicate 
that there were 6,155 firms in the category that operated for the entire year. Of these, 7,633 had annual 
receipts of under $10 million, and an additional 403 firms had receipts of between $10 million and $24, 
999,999. For providers of Custom Computer Programming Services, the Census Bureau data indicate 
that there were 32,269 firms that operated for the entire year. Of these, 31,416 had annual receipts of 
under $10 million, and an additional 565 firms had receipts of between $10 million and $24,999,999. 
Consequently, we estimate that the majority of the firms in this category are small entities that may be 
affected by our action. 

23. NCE and Public Broadcast Stations . The Census Bureau defines this category as follows: 
"This industry comprises establishments primarily engaged in broadcasting images together with sound. 
These establishments operate television broadcasting studios and facilities for the programming and 
transmission of programs to the public." 74 The SBA has created a small business size standard for 
Television Broadcasting entities, which is: such firms having $13 million or less in annual receipts. 75 
According to Commission staff review of the BIA Publications, Inc., Master Access Television Analyzer 
Database as of May 16, 2003, about 814 of the 1,220 commercial television stations in the United States 
had revenues of $12 (twelve) million or less. We note, however, that in assessing whether a business 
concern qualifies as small under the above definition, business (control) affiliations 76 must be included. 
Our estimate, therefore, likely overstates the number of small entities that might be affected by our action, 
because the revenue figure on which it is based does not include or aggregate revenues from affiliated 
companies. 



71 13 C.F.R. § 121.201, NAICS code 334220. 

72 

~ U.S. Census Bureau, American FactFinder, 2002 Economic Census, Industry Series, Industry Statistics by 
Employment Size, NAICS code 334220 (released May 26, 2005); http://factfinder.census.gov. The number of 
"establishments" is a less helpful indicator of small business prevalence in this context than would be the number of 
"firms" or "companies," because the latter take into account the concept of common ownership or control. Any 
single physical location for an entity is an establishment, even though that location may be owned by a different 
establishment. Thus, the numbers given may reflect inflated numbers of businesses in this category, including the 
numbers of small businesses. In this category, the Census breaks-out data for firms or companies only to give the 
total number of such entities for 2002, which was 929. 

73 

Id. An additional 18 establishments had employment of 1,000 or more. 

74 U.S. Census Bureau, 2002 NAICS Definitions, "515120 Television Broadcasting" (partial definition); 
http://www.census.gov/epcd/naics02/def/NDEF515.HTM . 

75 13 C.F.R. § 121.201, NAICS code 515120. 

76 "Concerns are affiliates of each other when one concern controls or has the power to control the other or a third 
party or parties controls or has to power to control both." 13 C.F.R. § 21.103(a)(1). 
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24. In addition, an element of the definition of "small business" is that the entity not be 
dominant in its field of operation. We are unable at this time to define or quantify the criteria that would 
establish whether a specific television station is dominant in its field of operation. Accordingly, the 
estimate of small businesses to which rules may apply do not exclude any television station from the 
definition of a small business on this basis and are therefore over-inclusive to that extent. Also as noted, 
an additional element of the definition of "small business" is that the entity must be independently owned 
and operated. We note that it is difficult at times to assess these criteria in the context of media entities 
and our estimates of small businesses to which they apply may be over-inclusive to this extent. There are 
also 2,1 17 low power television stations (LPTV). 77 Given the nature of this service, we will presume that 
all LPTV licensees qualify as small entities under the above SBA small business size standard. 

25. The Commission has, under SBA regulations, estimated the number of licensed NCE 
television stations to be 3 80. 78 We note, however, that, in assessing whether a business concern qualifies 
as small under the above definition, business (control) affiliations 79 must be included. Our estimate, 
therefore, likely overstates the number of small entities that might be affected by our action, because the 
revenue figure on which it is based does not include or aggregate revenues from affiliated companies. 
The Commission does not compile and otherwise does not have access to information on the revenue of 
NCE stations that would permit it to determine how many such stations would qualify as small entities. 

A. Description of Projected Reporting, Recordkeeping, and Other Compliance 
Requirements 

26. This Report and Order may contain new information collection requirements subject to 
the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. If the Commission determines that the 
Report and Order contains collection subject to the PRA, it will be submitted to the Office of 
Management and Budget (OMB) for review under section 3507(d) of the PRA at an appropriate time. At 
that time, OMB, the general public, and other Federal agencies will be invited to comment on the new or 
modified information collection requirements contained in this proceeding. In addition, we note that 
pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 
3506(c)(4), we previously sought specific comment on how the Commission might "further reduce the 
information collection burden for small business concerns with fewer than 25 employees. 

B. Steps Taken to Minimize the Significant Economic Impact on Small Entities, and 
Significant Alternatives Considered 

27. The RFA requires an agency to describe any significant alternatives that it has considered 
in developing its approach, which may include the following four alternatives (among others): "(1) the 
establishment of differing compliance or reporting requirements or timetables that take into account the 
resources available to small entities; (2) the clarification, consolidation, or simplification of compliance 
and reporting requirements under the rule for such small entities; (3) the use of performance rather than 
design standards; and (4) an exemption from coverage of the rule, or any part thereof, for such small 
entities." 80 

28. As noted in paragraph 2 above, this CMAS First Report and Order deals only with the 
WARN Act section 602(a) requirement that the Commission adopt technical standards, protocols, 
procedures, and other technical requirements based on the recommendations of the Commercial Mobile 



FCC News Release, "Broadcast Station Totals as of September 30, 2005." 

78 

See Broadcast Station Totals, supra IRFA, n. 11. 

79 

"[Business concerns] are affiliates of each other when one concern controls or has the power to control the other 
or a third party or parties controls or has to power to control both." 13 C.F.R. § 121.103(a)(1). 

80 5 U.S.C. § 603(c)(1) - (c)(4). 



48 



Federal Communications Commission 



FCC 08-99 



Service Alert Advisory Committee. The entities affected by this order were largely the members of the 
CMSAAC. In its formation of the CMSAAC, the Commission made sure to include representatives of 
small businesses among the advisory committee members. Also, as we indicate by our treatment of the 
comments of Interstate Wireless in paragraph 15 above, the technical requirements, standards and 
protocols on which the Commission sought comment already contain concerns raised by small 
businesses. 81 The WARN ACT NPRM also sought comment on a number of alternatives to the 
recommendations of the CMSAAC, such as the Digital EAS 82 and FM sub-carrier based alerts. 83 In its 
consideration of these and other alternatives the CMSAAC recommendations, the Commission has 
attempted to impose minimal regulation on small entities to the extent consistent with our goal of 
advancing our public safety mission by adopting technical requirements, standards and protocols for a 
CMAS that CMS providers would elect to provide alerts and warnings to their customers. The affected 
CMS providers have overwhelmingly expressed their willingness to cooperate in the formation of the 
CMAS, and we anticipate that the standards, protocols and requirement that we adopt in this order will 
encourage CMS providers to work with other industry and government entities to complete and 
participate in the CMAS. 

C. Federal Rules that May Duplicate, Overlap, or Conflict with the Proposed Rules 

29. None. 



See infra, n.53. 
See infra f 12. 
See infra f 33. 
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APPENDIX C 
Final Rules 

PART 10— COMMERCIAL MOBILE ALERT SYSTEM 

Subpart A — General Information 

Sec. 

10.1 Basis. 

10.2 Purpose. 

10.10 Definitions. 

10.11 CM AS Implementation Timeline. 

Subpart B — Election to Participate in Commercial Mobile Alert System 

Reserved. 

Subpart C — System Architecture 

Sec. 

10.300 Alert Aggregator (reserved). 
10.310 Federal Alert Gateway (reserved). 
10.320 Provider Gateway Requirements. 
10.330 Provider Infrastructure Requirements. 

Subpart D — Alert Message Requirements 

Sec. 

10.400 Classification. 

10.410 Prioritization. 

10.420 Message Elements. 

10.430 Character Limit. 

10.440 Embedded Reference Prohibition. 

10.450 Geographic Targeting. 

10.460 Retransmission Frequency (reserved). 

10.470 Roaming. 

Subpart E — Equipment Requirements 

Sec. 

10.500 General Requirements. 
10.510 Call Preemption Prohibition. 
10.520 Common Audio Attention Signal. 
10.530 Common Vibration Cadence. 
10.540 Attestation Requirement, (reserved). 

Subpart A — General Information 

§ 10.1 Basis. 

The rules in this part are issued pursuant to the authority contained in the Warning, Alert, and Response 
Network Act, Title VI of the Security and Accountability for Every Port Act of 2006, Pub. L. 109-347, 
Titles I through III of the Communications Act of 1934, as amended, and Executive Order 13407 of June 
26, 2006, Public Alert and Warning System, 71 Federal Register 36975 (2006). 
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§ 10.2 Purpose. 

The rules in this part establish the requirements for participation in the voluntary Commercial Mobile 
Alert System. 

§ 10.10 Definitions. 

(a) Alert Message. An Alert Message is a message that is intended to provide the recipient information 
regarding an emergency, and that meets the requirements for transmission by a Participating Commercial 
Mobile Service Provider under this part. 

(b) Common Alerting Protocol. The Common Alerting Protocol (CAP) refers to Organization for the 
Advancement of Structured Information Standards (OASIS) Standard CAP-V1.1, October 2005 (available 
at http://www.oasis-open.Org/specs/index.php#capv 1.1) , or any subsequent version of CAP adopted by 
OASIS and implemented by the CM AS. 

(c) Commercial Mobile Alert System. The Commercial Mobile Alert System (CMAS) refers to the 
voluntary emergency alerting system established by this part, whereby Commercial Mobile Service 
Providers may elect to transmit Alert Messages to the public. 

(d) Commercial Mobile Service Provider. A Commercial Mobile Service Provider (or CMS Provider) is 
an FCC licensee providing commercial mobile service as defined in section 332 (d)(1) of the 
Communications Act of 1934 (47 U.S.C. 332(d)(1)). Section 332(d)(1) defines the term commercial 
mobile service as any mobile service (as defined in 47 U.S.C. 153) that is provided for profit and makes 
interconnected service available (a) to the public or (b) to such classes of eligible users as to be effectively 
available to a substantial portion of the public, as specified by regulation by the Commission. 

(g) County and County Equivalent. The terms County and County Equivalent as used in this part are 
defined by Federal Information Processing Standards (FIPS) 6-4, which provides the names and codes 
that represent the counties and other entities treated as equivalent legal and/or statistical subdivisions of 
the 50 States, the District of Columbia, and the possessions and freely associated areas of the United 
States. Counties are considered to be the "first-order subdivisions" of each State and statistically 
equivalent entity, regardless of their local designations (county, parish, borough, etc.). Thus, the 
following entities are considered to be equivalent to counties for legal and/or statistical purposes: The 
parishes of Louisiana; the boroughs and census areas of Alaska; the District of Columbia; the independent 
cities of Maryland, Missouri, Nevada, and Virginia; that part of Yellowstone National Park in Montana; 
and various entities in the possessions and associated areas. The FIPS codes and FIPS code 
documentation are available online at http://www.itl.nist.gov/fipspubs/index.htm . 
(f) Participating Commercial Mobile Service Provider. A Participating Commercial Mobile Service 
Provider (or a Participating CMS Provider) is a Commercial Mobile Service Provider that has voluntarily 
elected to transmit Alert Messages under subpart B of this part. 

§ 10.11 CMAS Implementation Timeline. 

Notwithstanding anything in this part to the contrary, a Participating CMS provider shall comply with the 
rules in this part no later than 10 months from the date of announcement by the FCC of an entity or 
entities to provide the Alert Aggregator and Federal alert gateway functions. 

Subpart B — Election to Participate in Commercial Mobile Alert System 

Reserved. 



51 



Federal Communications Commission 



FCC 08-99 



Subpart C — System Architecture 



§ 10.300 



Alert Aggregator. 



Reserved. 



§ 10.310 



Federal Alert Gateway. 



Reserved. 



§ 10.320 



Provider Alert Gateway Requirements. 



This section specifies the functions that each Participating Commercial Mobile Service provider is 
required to support and perform at its CMS provider gateways. 

(a) General. The CMS provider gateway must provide secure, redundant, and reliable connections to 
receive Alert Messages from the Federal alert gateway. Each CMS provider gateway must be identified 
by a unique IP address or domain name. 

(b) Authentication and Validation. The CMS provider gateway must authenticate interactions with the 
Federal alert gateway, and validate Alert Message integrity and parameters. The CMS provider gateway 
must provide an error message immediately to the Federal alert gateway if a validation fails. 

(c) Security. The CMS provider gateway must support standardized IP-based security mechanisms such 
as a firewall, and support the defined CMAS "C" interface and associated protocols between the Federal 
alert gateway and the CMS provider gateway. 

(d) Geographic Targeting. The CMS provider gateway must determine whether the provider has elected 
to transmit an Alert Message within a specified alert area and, if so, map the Alert Message to an 
associated set of transmission sites. 

(e) Message Management. 

(1) Formatting. The CMS provider gateway is not required to perform any formatting, reformatting, or 
translation of an Alert Message, except for transcoding a text, audio, video, or multimedia file into the 
format supported by mobile devices. 

(2) Reception. The CMS provider gateway must support a mechanism to stop and start Alert Message 
deliveries from the Federal alert gateway to the CMS provider gateway. 

(3) Prioritization. The CMS provider gateway must process an Alert Message on a first in-first out basis 
except for Presidential Alerts, which must be processed before all non-Presidential alerts. 

(4) Distribution. A Participating CMS provider must deploy one or more CMS provider gateways to 
support distribution of Alert Messages and to manage Alert Message traffic. 

(5) Retransmission. The CMS provider gateway must manage and execute Alert Message retransmission, 
and support a mechanism to manage congestion within the CMS provider's infrastructure. 

(f) CMS Provider Profile. The CMS provider gateway will provide profile information on the CMS 
provider for the Federal alert gateway to maintain at the Federal alert gateway. This profile information 
must be provided by an authorized CMS provider representative to the Federal alert gateway 
administrator. The profile information must include the data listed in Table 10.320(f) and must comply 
with the following procedures: 

(1) The information must be provided 30 days in advance of the date when the CMS provider begins to 
transmit CMAS alerts. 

(2) Updates of any CMS provider profiles must be provided in writing at least 30 days in advance of the 
effective change date. 
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Table 10.320(f) CMSP Profile on Federal Alert Gateway 



Profile Parameter 


Parameter Election 


Description 


CMSP Name 




Unique identification of CMSP 


CMSP gateway Address 


IP address or Domain 
Name 






Alternate IP address 


Optional and subject to 
implementation 


Geo-Location Filtering 


<yes / no> 


If "yes" the only CMAM issued in 
the listed states will be sent to the 
CMSP gateway. 

If "no", all CMAM will be sent to the 
CMSP gateway. 


If yes, list of states 


CMAC Geocode for state 


List can be state name or abbreviated 
state name. 



§ 10.330 Provider Infrastructure Requirements. 

This section specifies the general functions that a Participating CMS Provider is required to perform 
within their infrastructure. Infrastructure functions are dependent upon the capabilities of the delivery 
technologies implemented by a Participating CMS Provider. 

(a) Distribution of Alert Messages to mobile devices. 

(b) Authentication of interactions with mobile devices. 

(c) Reference Points D & E. Reference Point D is the interface between a CMS Provider gateway and its 
infrastructure. Reference Point E is the interface between a provider's infrastructure and mobile devices 
including air interfaces. Reference Points D and E protocols are defined and controlled by each 
Participating CMS Provider. 

Subpart D — Alert Message Requirements 

§ 10.400 Classification. 

A Participating CMS Provider is required to receive and transmit three classes of Alert Messages: 
Presidential Alert; Imminent Threat Alert; and Child Abduction Emergency /AMBER Alert. 

(a) Presidential Alert. A Presidential Alert is an alert issued by the President of the United States or the 
President's authorized designee. 

(b) Imminent Threat Alert. An Imminent Threat Alert is an alert that meets a minimum value for each of 
three CAP elements: Urgency, Severity, and Certainty. 

(1) Urgency. The CAP Urgency element must be either Immediate (i.e., responsive action should be 
taken immediately) or Expected (i.e., responsive action should be taken soon, within the next hour). 

(2) Severity. The CAP Severity element must be either Extreme (i.e., an extraordinary threat to life or 
property) or Severe (i.e., a significant threat to life or property). 

(3) Certainty. The CAP Certainty element must be either Observed (i.e., determined to have occurred or 
to be ongoing) or Likely (i.e., has a probability of greater than 50 percent). 
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(c) Child Abduction Emergency/ 'AMBER Alert. An AMBER Alert is an alert initiated by a local 
government official based on the U.S. Department of Justice's five criteria that should be met before an 
alert is activated: (1) law enforcement confirms a child has been abducted; (2) the child is 17 years or 
younger; (3) law enforcement believes the child is in imminent danger of serious bodily harm or death; 
(4) there is enough descriptive information about the victim and the abduction to believe an immediate 
broadcast alert will help; and (5) the child's name and other data have been entered into the National 
Crime Information Center. There are four types of AMBER Alerts: Family Abduction; Non-family 
Abduction; Lost, Injured or Otherwise Missing; and Endangered Runaway. 

(1) Family Abduction. A Family Abduction (FA) alert involves an abductor who is a family member of 
the abducted child such as a parent, aunt, grandfather, or stepfather. 

(2) Nonfamily Abduction. A Nonfamily Abduction (NFA) alert involves an abductor unrelated to the 
abducted child, either someone unknown to the child and/or the child's family or an acquaintance/friend 
of the child and/or the child's family. 

(3) Lost, Injured, or Otherwise Missing. A Lost, Injured, or Otherwise Missing (LIM) alert involves a 
case where the circumstances of the child's disappearance are unknown. 

(4) Endangered Runaway. An Endangered Runaway (ERU) alert involves a missing child who is 
believed to have run away and in imminent danger. 

§ 10.410 Prioritization. 

A Participating CMS Provider is required to transmit Presidential Alerts upon receipt. Presidential Alerts 
preempt all other Alert Messages. A Participating CMS Provider is required to transmit Imminent Threat 
Alerts and AMBER Alerts on a first in-first out (FIFO) basis. 

§ 10.420 Message Elements. 

A CMAS Alert Message processed by a Participating CMS Provider shall include five mandatory CAP 
elements — Event Type; Area Affected; Recommended Action; Expiration Time (with time zone); and 
Sending Agency. This requirement does not apply to Presidential Alerts. 

§ 10.430 Character Limit. 

A CMAS Alert Message processed by a Participating CMS Provider must not exceed 90 characters of 
alphanumeric text. 

§ 10.440 Embedded Reference Prohibition. 

A CMAS Alert Message processed by a Participating CMS Provider must not include an embedded 
Uniform Resource Locator (URL), which is a reference (an address) to a resource on the Internet, or an 
embedded telephone number. This prohibition does not apply to Presidential Alerts. 

§ 10.450 Geographic Targeting. 

This section establishes minimum requirements for the geographic targeting of Alert Messages. A 
Participating CMS Provider will determine which of its network facilities, elements, and locations will be 
used to geographically target Alert Messages. A Participating CMS Provider must transmit any Alert 
Message that is specified by a geocode, circle, or polygon to an area not larger than the provider's 
approximation of coverage for the Counties or County Equivalents with which that geocode, circle, or 
polygon intersects. If, however, the propagation area of a provider's transmission site exceeds a single 
County or County Equivalent, a Participating CMS Provider may transmit an Alert Message to an area 
not exceeding the propagation area. 
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§ 10.460 



Retransmission Frequency. 



Reserved. 



§ 10.470 



Roaming. 



When, pursuant to a roaming agreement (see § 20.12 of the Commission's rules), a subscriber receives 
services from a roamed-upon network of a Participating CMS Provider, the Participating CMS Provider 
must support CMAS alerts to the roaming subscriber to the extent the subscriber's mobile device is 
configured for and technically capable of receiving CMAS alerts.. 

Subpart E — Equipment Requirements 

§ 10.500 General Requirements. 

CMAS mobile device functionality is dependent on the capabilities of a Participating CMS Provider' s 
delivery technologies. Mobile devices are required to perform the following functions: 

(a) Authentication of interactions with CMS Provider infrastructure. 

(b) Monitoring for Alert Messages. 

(c) Maintaining subscriber alert opt-out selections, if any. 

(d) Maintaining subscriber alert language preferences, if any. 

(e) Extraction of alert content in English or the subscriber's preferred language, if applicable. 

(f) Presentation of alert content to the device, consistent with subscriber opt-out selections. Presidential 
Alerts must always be presented. 

(g) Detection and suppression of presentation of duplicate alerts. 
§ 10.510 Call Preemption Prohibition. 

Devices marketed for public use under Part 10 must not enable an Alert Message to preempt an active 
voice or data session. 

§ 10.520 Common Audio Attention Signal. 

A Participating CMS Provider and equipment manufacturers may only market devices for public use 
under Part 10 that include an audio attention signal that meets the requirements of this section. 

(a) The audio attention signal must have a temporal pattern of one long tone of two (2) seconds, followed 
by two short tones of one (1) second each, with a half (0.5) second interval between each tone. The entire 
sequence must be repeated twice with a half (0.5) second interval between each repetition. 

(b) For devices that have polyphonic capabilities, the audio attention signal must consist of the 
fundamental frequencies of 853 Hz and 960 Hz transmitted simultaneously. 

(c) For devices with only a monophonic capability, the audio attention signal must be 960 Hz. 

(d) The audio attention signal must be restricted to use for Alert Messages under Part 10. 

(e) A device may include the capability to mute the audio attention signal. 

§ 10.530 Common Vibration Cadence. 

A Participating CMS Provider and equipment manufacturers may only market devices for public use 
under Part 10 that include a vibration cadence capability that meets the requirements of this section. 

(a) The vibration cadence must have a temporal pattern of one long vibration of two (2) seconds, followed 
by two short vibrations of one (1) second each, with a half (0.5) second interval between each vibration. 
The entire sequence must be repeated twice with a half (0.5) second interval between each repetition. 

(b) The vibration cadence must be restricted to use for Alert Messages under Part 10. 
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(c) A device may include the capability to mute the vibration cadence. 
§ 10.540 Attestation Requirement. 

Reserved. 
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STATEMENT OF 
CHAIRMAN KEVIN J. MARTIN 

Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 

With the American public increasingly relying on wireless communications in everyday life, it is 
essential that we support and advance new ways to share critical, time-sensitive information with them in 
times of crisis. The ability to deliver accurate and timely warnings and alerts through cell phones and 
other mobile devices is an important next step in our efforts to help ensure that the American public has 
the information they need to take action to protect themselves and their families prior to, and during, 
disasters and other emergencies. The Commercial Mobile Services Alert Advisory Committee's 
recommendations were instrumental in moving this process forward. I commend them for their efforts 

No one questions the value that an effective Commercial Mobile Alert System will have on the 
safety and welfare of the American public. Accordingly, we welcomed the challenge offered to us by the 
WARN Act as an opportunity to meet our public safety obligations under the Communications Act and to 
achieve one of our top priorities - an effective alert system for wireless devices. 

By adopting technical requirements for the wireless alerting system today, we are enabling 
wireless providers that choose to participate in this system to begin designing their networks to deliver 
mobile alerts. It would have been better, of course, if we had a Federal entity in place now to take on the 
role of alert aggregator and gateway. We are hopeful that we have initiated the dialogue that will allow 
an appropriate Federal entity to assume that central role in an expeditious manner. 

This system has the potential to significantly impact the way Americans receive critical warnings 
on the go, whether they are at home, work, or vacationing. As we go forward, given the important public 
safety purpose that these alerts serve, I encourage wireless providers to participate fully in this valuable 
system. 
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STATEMENT OF 
COMMISSIONER MICHAEL J. COPPS 

Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 

Today's Order creates a framework for delivering emergency alerts to American mobile phones, 
as required by the Warning Alert Response Network (WARN) Act. Extending the nation's emergency 
alert system to mobile phones is an enormous step forward. Now Americans will be able to receive 
warnings about dangerous weather and other imminent threats (including man-made threats like a terrorist 
attack) in their immediate area, even if they are not near a television set or radio and even if their 
electrical power is down. This is good news for all of us — especially in these dangerous times. 

I also think it is significant that today's Order arises out of cooperation — through a process 
established by the WARN Act — among public safety representatives; government at the state, local and 
federal level; federally -recognized Indian tribes; industry; and national organizations representing those 
with special needs. For the most part, the work of the Commercial Mobile Service Alert Advisory 
Committee (established by the WARN Act) has been a model of how difficult and important decisions 
can be reached, and consensus forged, even among diverse stakeholders. 

The many experts who dedicated their time and energy to this important effort have made today's 
decision far more informed, and responsive to technical realities, than it otherwise would be. I thank 
them for their service, and I hope that this spirit of cooperation and shared dedication to improving public 
safety can serve as a model for other public safety issues before the Commission. To be sure, there will 
be times when the agency cannot forge consensus and must act based on the best available evidence 
before it — because doing so is sometimes necessary to protect the American public. But the fact remains 
that the Commission and industry are both capable of reaching better outcomes when we work 
cooperatively, and I hope we can do so more often in the months and years ahead. 

Unfortunately, there is one final issue that remains unresolved by today's Order — an issue that, if 
left uncorrected, threatens to vitiate it entirely. So far, no federal agency has stepped up to fulfill the 
unified aggregator/gateway role that virtually all stakeholders agree is necessary for our mobile alert 
system to work properly. Indeed, if no agency assumes this role, the rules we enact today will never 
become effective and Americans will never receive the protection of emergency alerts delivered to their 
mobile phones. 

The unwillingness of the Federal Emergency Management Agency (FEMA) to fulfill this role is 
especially disheartening because FEMA representatives were intimately involved in developing the idea 
of a unified Federal gateway /aggregator. In fact, not until long after the die was cast, did FEMA suggest 
that it would be unable for statutory and other reasons to perform this key function. Specifically, it was 
less than two months ago — after the advisory committee had made its recommendation and after 
FEMA's representative had voted in favor of the unified Federal gateway /aggregator scheme — before 
FEMA raised any objection to assuming this responsibility. 

So now we are left without a firm candidate for a position that is essential to getting this system 
off the ground. In light of FEMA's recent and unexpected interpretation of its statutory authority, the 
Commission's only remaining option is to work with its fellow agencies and the Congress to find a 
federal entity (whether FEMA, another branch of the Department of Homeland Security, or some other 
government agency) that can fulfill this function. 

I certainly wish it had not come to this. Indeed, I would not be shy about suggesting that the FCC 
take on this function itself — except that our agency (unlike FEMA, the Department of Justice, and the 
National Oceanic and Atmospheric Agency) does not currently have experience with originating 
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emergency alerts; has not received appropriations for operating an emergency alert system (as FEMA 
has); and does not have statutory authority to borrow money against the DTV Transition Fund to 
implement the WARN Act (as the Departments of Homeland Security and Commerce have). 

The time may come when the FCC must consider whether to begin the task of creating this 
infrastructure here at our own agency, and I will not hesitate to head down this road if it looks like the 
fastest and most effective way to bring mobile emergency alerts to the American people. But for now the 
most fruitful path appears to be working with the Congress and our fellow federal agencies to see if an 
institution with experience originating emergency alerts is willing and able to assume this role for the 
CMAS system. I hope — for all of our sakes — that one will be. 
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STATEMENT OF 
COMMISSIONER JONATHAN S. ADELSTEIN 

Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 

The prompt and accurate delivery of national, state and local messages to ensure the safety and 
security of the American people during natural or man-made disasters is critical. Today's Report and 
Order marks our efforts towards ensuring that there are technologically neutral rules in place to enable 
commercial mobile service providers to elect to provide these critical alerts to their customers. With over 
250 million subscribers of wireless services as of the end of this year, the ability of carriers to transmit 
emergency alerts to the public via commercial mobile devices is an urgently needed next step. 

One of the central purposes for the very creation of the FCC is to promote the safety of life and 
property of all Americans. The Commission has taken its important role in prescribing these rules very 
seriously, so I am pleased to support this decision. This significant step forward is due, in large part, to 
the dedication of state and local governments, industry and other participants that worked collaboratively 
to provide us with their recommendations. It is worth remembering that, as an elective system, it was vital 
that the rules implementing the Commercial Mobile Alert System were based upon the coordinated efforts 
of those that will implement and utilize this system. Collaboration, communication and cooperation have 
been key to this process. The effectiveness of this emergency alert system rests on the good-faith of all 
participating entities and I expect this will go a long way in ensuring mobile service providers elect to 
provide these emergency alerts. 

I would like to extend my sincere gratitude to the members of the Commercial Mobile Service 
Alert Advisory Committee who worked diligently through this important process. 
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STATEMENT OF 
COMMISSIONER DEBORAH TAYLOR TATE 

Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 

With over 255 million Americans subscribing to mobile telephone service, it is critical to public 
safety and homeland security that the nation's emergency alert system include wireless alerts. To that 
end, in 2006 Congress established, via the WARN Act, a process to create a mobile emergency alert 
system. Today we take an important step in fulfilling this goal. 

I particularly wish to thank the representatives from industry; public safety providers; local, state 
and federal government agencies; and others who participated in the Commercial Mobile Service Alert 
Advisory Committee. The Federal Communications Commission should not - and in this case, can not - 
perform its duties without the help of such a broad coalition, especially the service providers who 
ultimately must transmit emergency alerts. I also wish to acknowledge Sen. Jim DeMint for his 
leadership in sponsoring the WARN Act and his guidance in its implementation. Finally, the excellent 
staff of the Public Safety and Homeland Security Bureau deserve recognition for their consistent 
dedication to this effort. 
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STATEMENT OF 
COMMISSIONER ROBERT M. MCDOWELL 



Re: The Commercial Mobile Alert System, First Report and Order, PS Docket No. 07-287 

At the outset, I want to acknowledge and thank Lisa Fowlkes, Jean Ann Collins and all of the 
team in the Public Safety and Homeland Security Bureau for their hard work. This project has 
congressionally-mandated deadlines, and they have stayed focused on their tasks to produce a great deal 
of excellent work in a short period of time. 

I also want to thank the folks from private industry and public safety who are so generously 
giving of their time and expertise to serve on the Commercial Mobile Service Alert Advisory Committee 
and participate in this important process. This project is an excellent example of the wonderful benefits 
that flow from a government-industry collaboration. I am pleased that the Commission has had a leading 
role in the meaningful partnership among the commercial wireless industry, technology providers and 
public safety entities. 

By harnessing the expertise of all interested stakeholders, we have made great strides toward the 
roll-out of an expanded emergency alert system. We will all benefit from the important work this group 
has undertaken, and I look forward to continuing to work with all of you as we complete the next set of 
benchmarks. At this point, the Commission is already well poised to "get out of the way" and let the 
private sector deliver the new alert system for the benefit of America's wireless consumers. 
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